Trouble Accessing page specified by AuthExpiredURL Metabase entry

am 05.01.2007 21:58:31 von Kenneth Baltrinic

I am a lead .Net developer on a large government web application running on
IIS 6.0/Win 2003 Server. We are using basic authentication over SSL
authenticating against an active directory. There is a new mandate that we
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 can
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 second
web application on the IIS server that permits anonymous access and will
host a password change page. We have set the AuthExpiredURL metabase entry
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 change
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 redirected
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 not
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 layer.
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 what
exactly is going on or what is different between the redirected call to the
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.

Re: Trouble Accessing page specified by AuthExpiredURL Metabase entry

am 06.01.2007 21:15:09 von David Wang

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/archive/2005/07/14/HOWTO_Di agnose_IIS_401_Access_Denied.aspx
http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Ba sics_of_IIS6_Troubleshooting.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 on
> IIS 6.0/Win 2003 Server. We are using basic authentication over SSL
> authenticating against an active directory. There is a new mandate that we
> 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 can
> 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 second
> web application on the IIS server that permits anonymous access and will
> host a password change page. We have set the AuthExpiredURL metabase entry
> 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 change
> 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 redirected
> 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 not
> 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 layer.
> 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 what
> exactly is going on or what is different between the redirected call to the
> 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.

Re: Trouble Accessing page specified by AuthExpiredURL Metabase entry

am 06.01.2007 21:15:09 von David Wang

Re: Trouble Accessing page specified by AuthExpiredURL Metabase entry

am 08.01.2007 19:44:50 von Kenneth Baltrinic

Bingo!

Dave,

Thanks, you were right about 403.18. I placed both applications in the same
pool and now it all works. Thanks for the resource links as well.

--Ken

"David Wang" wrote in message
news:1168114509.894181.236230@s34g2000cwa.googlegroups.com.. .
> 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/archive/2005/07/14/HOWTO_Di agnose_IIS_401_Access_Denied.aspx
> http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Ba sics_of_IIS6_Troubleshooting.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
>> on
>> IIS 6.0/Win 2003 Server. We are using basic authentication over SSL
>> authenticating against an active directory. There is a new mandate that
>> we
>> 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
>> can
>> 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
>> second
>> web application on the IIS server that permits anonymous access and will
>> host a password change page. We have set the AuthExpiredURL metabase
>> entry
>> 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
>> change
>> 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
>> redirected
>> 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
>> not
>> 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
>> layer.
>> 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
>> what
>> exactly is going on or what is different between the redirected call to
>> the
>> 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.
>

Re: Trouble Accessing page specified by AuthExpiredURL Metabase entry

am 08.01.2007 19:44:50 von Kenneth Baltrinic