Re: Cached Logon

From: Roger Abell (mvpNoSpam_at_asu.edu)
Date: 12/22/04 

Date: Wed, 22 Dec 2004 07:15:57 -0700

"Roland Hall" <nobody@nowhere> wrote in message
news:OqNjkx%235EHA.3736@TK2MSFTNGP10.phx.gbl...
> "Ken Schaefer" wrote in message
> news:Oo7Cj695EHA.2608@TK2MSFTNGP10.phx.gbl...
> :
> : "Roland Hall" <nobody@nowhere> wrote in message
> : news:uaDiFu95EHA.1596@tk2msftngp13.phx.gbl...
> : > "Ken Schaefer" <kenREMOVE@THISadopenstatic.com> wrote in message
> : > news:uBfCwRi5EHA.3756@TK2MSFTNGP14.phx.gbl...
> : > : Hi,
> : > :
> : > : Your browser is caching the credentials, and resending them for each
> : > : subsequent page request to that server (until the browser is
closed).
> : >
> : > The cache was cleared and the browser was closed and still it failed
but
> I
> : > was prompted each time for credentials but only for the first page.
> :
> : I think you are completely missing the point, or I am not understanding
> what
> : you are saying.
> :
> : When the browser connects to "firstpage.asp", it first attempts to
connect
> : anonymously (sending no credentials). The webserver sends back a 401
> header
> : (Access Denied) and lists available authentication mechanisms via
> : WWW-Authenticate HTTP headers.
> :
> : The browser then prompts the user to supply credentials (or, in the case
> of
> : IE, if the website is in the local intranet security zone, will attempt
to
> : send the current logged on user's credentials automatically). The user
> : supplies their credentials, and the browser sends them to the server. If
> the
> : credentials are acceptable, the server sends back a 200 OK status.
> :
> : The browser then continues to reuse those credentials for subsequent
> : requests for pages on that site. This is why (I suspect) you are not
> seeing
> : credential prompts on subsequent pages. You can not "clear" this cache
per
> : se. Instead, when you close the browser completely, the browser
"forgets"
> : the credentials it has been using. When you open the browser again
(well,
> : technically you need to start a new iexplore.exe process) and hit the
site
> : again, you will once again be prompted for credentials
> :
> : > : In terms of the login failure - can we see the exact error message
> that
> : > : you are seeing please?
> : >
> : > Error Type:
> : > Microsoft OLE DB Provider for SQL Server (0x80040E4D)
> : > Login failed for user 'sa'.
> : > /msft/StraightASP.asp, line 7
> :
> : Well, for some reason SQL Server thinks that the password being supplied
> by
> : your ADO connection object is not correct for the "sa" account.
> :
> : This doesn't have anything to do with IIS caching a logon (for the
> purposes
> : impersonating an NT account for processing an ASP page), or with HTTP
> : authentication between the client and server, which is what your
original
> : post seemed to be talking about. This seems to be an authentication
issue
> : between your ADO components and SQL Server.
> :
> : That said, if you've cut-n-pasted the code from one working page to
> another
> : page, that does seem "out of the norm". Just as a trial, could you put
the
> : connection string into an include file, and include that into your two
> : pages, and then use the connection string from the include file? That
> would
> : probably eliminate some odd non-printable character (or something
similar)
> : being in the connection string. Both pages should either work, or not
> work.
>
> Ken...
>
> I provided the link at MSFT where I got the files. You can see for
yourself
> there are no non-printable characters. Again, this is not my code. Also,
I
> cannot reproduce the problem now that the server has been rebooted.
You're
> also apparently excluding the other particulars.
>
> If the sa logon fails, it should fail no matter which file is trying to
> authenticate as long as that code is the same. Renaming the file, makes
it
> work. Renaming it back to the original name makes it fail once again.

This is the most perplexing part. And, as you mentioned in post of the
other
subthread, you could close all IE processes, start again, and see the same
pattern (prior to the rebooting). That the file name should be so important
is not simple to understand, and makes it sound as if there was a corruption
in IIS's caching of the file involved. 

-- 
Roger
> However, nothing fails now that the server has been rebooted. Explain to
me
> how the code has anything to do with that.  Also, since event viewer shows
> nothing, where can I get information regarding the failed logon?
>
> TIA...
>
> -- 
> Roland Hall
> /* This information is distributed in the hope that it will be useful, but
> without any warranty; without even the implied warranty of merchantability
> or fitness for a particular purpose. */
> Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
> WSH 5.6 Documentation -
http://msdn.microsoft.com/downloads/list/webdev.asp
> MSDN Library - http://msdn.microsoft.com/library/default.asp
>
>

Relevant Pages

  • Re: Cached Logon
    ... supplies their credentials, and the browser sends them to the server. ... nothing fails now that the server has been rebooted. ...
    (microsoft.public.inetserver.iis)
  • Re: Cached Logon
    ... supplies their credentials, and the browser sends them to the server. ... nothing fails now that the server has been rebooted. ...
    (microsoft.public.sqlserver.security)
  • Re: Cached Logon
    ... supplies their credentials, and the browser sends them to the server. ... nothing fails now that the server has been rebooted. ...
    (microsoft.public.windows.server.general)
  • Re: Cached Logon
    ... supplies their credentials, and the browser sends them to the server. ... nothing fails now that the server has been rebooted. ...
    (microsoft.public.sqlserver.connect)
  • Re: Cached Logon
    ... supplies their credentials, and the browser sends them to the server. ... nothing fails now that the server has been rebooted. ...
    (microsoft.public.sqlserver.server)