01-09-07 06:50 AM
Looking in the HTTP.SYS log file, IIS log file, and Windows event log
are amongst the best ways to figure out what is going on within a
server.
http://blogs.msdn.com/david.wang/ar.../>
Denied.aspx
http://blogs.msdn.com/david.wang/ar.../>
ooting.aspx
Please:
1. check the IIS log file for more information on what type of 403 is
being returned by IIS for the redirected request.
2. provide the exact request (including request headers) as well as the
401 and 403 responses returned by IIS. Their corresponding log file
entry in IIS is also useful.
The lack of documentation for password changing is quite intentional --
it's not really a "public feature" meant to be used.
I believe you are seeing a 403.18 response from IIS, which happens when
a Server-Side redirection crosses different Application Pools. This is
a possible difference between a direct call and a server-side
redirected call to the PasswordChange page.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
Kenneth Baltrinic wrote:
> I am a lead .Net developer on a large government web application running o
n
> IIS 6.0/Win 2003 Server. We are using basic authentication over SSL
> authenticating against an active directory. There is a new mandate that w
e
> implement a password change function that allows users with expired
> passwords to change their password.
>
>
>
> We already have in our system functionality where an authenticated user ca
n
> update their password. However, if the password is already expired, the
> user cannot authenticate in order to access that functionality.
>
>
>
> Our approach to implementing the new requirement has been to set up a seco
nd
> web application on the IIS server that permits anonymous access and will
> host a password change page. We have set the AuthExpiredURL metabase entr
y
> to point to the appropriate page in the new application and also set the
> PasswordChangeFlags value to 6.
>
>
>
> Using internet explorer 6.0, we can directly navigate to the password chan
ge
> page without authenticating and a user with an expired account can update
> their password via this page.
>
>
>
> When attempting to log into our secure application with an expired account
,
> we get redirected to the password change page but get a 403 response from
> that page. This is the crux of our dilemma. Why can we hit the password
> change page directly with anonymous access, but can't hit it when redirect
ed
> to it from our secure application?
>
>
>
> To further research this issue, we loaded an HTTP traffic monitor plug-in
> into I.E. and compared the results to the IIS logs. Our objective was to
> compare the direct request for the password change page to the redirected
> request. However, when calling our secure application, the two logs do no
t
> match.
>
>
>
> On IIS, we see two separate GET requests. The initial one requests the
> secure application's default page and results in a 401 response. This is
> followed immediately by a GET request for the password change page which
> results in a 403 response.
>
>
>
> On the client, we see only the original request to the secure application'
s
> default page, and it receives the final 403 response.
>
>
>
> This seems to indicate that the redirection from the secure application to
> the password change page is being performed on the IIS server exclusively,
> using some sort of proxy mechanism that is outside of the IIS logging laye
r.
> It seems this "proxy" is intercepting the 401 response and generating the
> second call to the AuthExpiredURL and passing that response back to the
> browser.
>
>
> Due to the paucity of documentation on the PasswordChangeFlags,
> AuthExpiredURL and related functionality we are at a loss to figure out wh
at
> exactly is going on or what is different between the redirected call to th
e
> password change page and a direct call from the browser to the page. The
> former fails when the latter succeeds. We need to understand why this is
> and how do we get the redirect to work?
>
>
>
> Any light you can shed on this matter, or if you can recommend a better
> solution that using the AuthExpiredURL setting, we would be in your debt.
>
>
>
> Thank you in advance for your time.
[ Post a follow-up to this message ]
| 
