Re: Integrated Windows Authentication, Change IE's Reaction to a 401.3

From: Karl Levinson [x y] mvp (levinson_k@excite.com)
Date: 12/20/02 

From: "Karl Levinson [x y] mvp" <levinson_k@excite.com>
Date: Fri, 20 Dec 2002 15:13:48 -0500

That's a good point... or what about the logon screen that appears when
Windows boots up?

I'm not aware of a way to change IE's behavior on this. However, I've never
heard anyone else express this as a security concern. A hacker would bring
his or her own tools along in order to start hacking, she needs no
invitation.

The typical way to handle something like this is to enable auditing and
monitor the Windows event logs for repeated failed logon attempts.
www.ipsentry.com will do this for around $125 US, or you can write a batch
file along with something like the DUMPEL.EXE utility from the Windows
Resource Kit [which is not free] and set it to dump all failed logon
attempts to a text file after backing up the previous copy of that file, and
then compare the two files and send you an email using BLAT or a NET SEND
message to alert you with a copy of the text file. I would recommend
running DUMPEL locally on each computer it is monitoring, since the results
of dumping the security event log seem to me to be wildly inaccurate when
run remotely for some odd reason.

Since any anonymous user on your network needs to be able to attempt a
login, you won't be able to block brute force cracking like this, so you
make sure it is very unlikely to succeed and then monitor suspicious events.

"Mike" <soniic@hotmail.com> wrote in message
news:72fd02c8.0212201135.8388f94@posting.google.com...
> Hello
>
> Just something to keep in mind: You mentioned that you didn't want IE
> to display a login prompt because it was an invitation for hackers to
> try and crack a login/password that would work.
>
> However, if you were able to supress this prompt, users could still
> start IE by using the "Run As" option and trying to crack a
> login/password that way. This would require virutally no extra
> effort!
>
> Just a thought.
>
> take care
> -Mike
>
>
>
> disneynoble@comcast.net (Rudie Noble) wrote in message
news:<360143d5.0212200754.73210602@posting.google.com>...
> > Using Integrated Windows Authentication on a Windows 2000 Server
> > running IIS that is acting as an Intranet server. Trying to find a
> > way to eliminate the login prompt that IE generates following an
> > authenticated user's attempt to access a web page in a subdirectory
> > that has been protected by limiting rights (ACL) to selective user
> > groups. IIS generates 401.3 and IE reacts by displaying a login
> > prompt.
> >
> >
> > More Details......
> >
> > Integrated Windows Authentication (also known as IWA, NT
> > Challenge/Response, and NTLM), seems well suited for an intranet
> > environment, since both user and Web server are in the same domain and
> > we can ensure that every user has Microsoft Internet Explorer (an IWA
> > requirement). Our Intranet site has pages that are both public and
> > some that are restricted by user group. Based on information
> > contained in other forum postings it is my understanding that when an
> > attempt to access a page from within a directory that specifies
> > Integrated Windows Authentication, IIS does not initially prompt the
> > user for a user name and password.
> >
> > The current Windows user information on the client computer is used
> > for authentication. IWA is a secure form of authentication because
> > the user name and password are not sent across the network. When you
> > enable IWA, the user's browser proves its knowledge of the password
> > through a cryptographic exchange with your Web server, involving
> > hashing.
> >
> > However, if this authentication exchange initially fails to identify
> > the user (such as when a user is not currently logged into the
> > network), the browser will prompt the user for a Windows user name and
> > password. In our case the user is logged onto the network and the
> > authentication is successful, but the identified user just doesn't
> > have access rights (via ACL) to the HTML file.
> >
> > When our users attempt to access such a restricted page IIS generates
> > a 401.3 and as a result IE issues a login prompt. It is my
> > understanding that it is IE making the decision to issue the prompt,
> > not IIS. This would give the user an opportunity to enter alternate
> > credentials that might have access rights. However, we want to just
> > deny access to that page because our users have no other id.
> >
> > We see no need for this prompt, it's way too much of an invitation to
> > try and hack the system. These users were correctly logged onto the
> > session; they just don't have permission to this page. Displaying
> > either the 401.3 error page or the 401.1 error page (which is what
> > gets displayed after canceling out of the login prompt) would be fine
> > (and yes I know these messages can be customized).
> >
> > I remain hopeful someone will know how to influence IE's behavior so
> > that it does not issue the logon prompt.
> >
> > Rudie Noble
> > Director, Distributed Computing
> > Frank's Nursery