Unable to authenticate via kerberos to IIS site accepting client c

Hello all,

After spending a few hours searching the web, I post this message to this
newsgroup just in case what seems to me an strange behaviour could be due to
IIS.

I'm trying to access a web service hosted in an IIS site configured to
accept both "Integrated Windows authentication" and "client certificates"
using an "https:" Uri. The client is a WinForm application in .Net 2.0.

When I configure the web service proxy to use client certificates it works
OK (the cert is mapped to a Windows account and the web service runs).
However, if I configure it to use the integrated Windows credentials, it
hangs.

Perhaps the .Net proxy configuration is more complex than I suspect, but I
post the doubt to this newsgroup just in case that IIS shouldn't be
configured that way for any reason. Summarising, should it be possible to
access an IIS site thru an "https:" Uri using either Windows integrated
authentication or client certificates?

Any help will be appreciated. Many thanks.

Re: Unable to authenticate via kerberos to IIS site accepting client c

Windows Integrated Authentication works over HTTPS. Independent of
Client-Cert mapping.

On which network leg does the network proxy happen? Because Integrated
Authentication user token cannot be "proxied" downstream by default.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//


On Jan 31, 2:27 am, jacorona
wrote:
> Hello all,
>
> After spending a few hours searching the web, I post this message to this
> newsgroup just in case what seems to me an strange behaviour could be due to
> IIS.
>
> I'm trying to access a web service hosted in an IIS site configured to
> accept both "Integrated Windows authentication" and "client certificates"
> using an "https:" Uri. The client is a WinForm application in .Net 2.0.
>
> When I configure the web service proxy to use client certificates it works
> OK (the cert is mapped to a Windows account and the web service runs).
> However, if I configure it to use the integrated Windows credentials, it
> hangs.
>
> Perhaps the .Net proxy configuration is more complex than I suspect, but I
> post the doubt to this newsgroup just in case that IIS shouldn't be
> configured that way for any reason. Summarising, should it be possible to
> access an IIS site thru an "https:" Uri using either Windows integrated
> authentication or client certificates?
>
> Any help will be appreciated. Many thanks.

Re: Unable to authenticate via kerberos to IIS site accepting clie

Thank you for answering, David.

The setup to test this strange behaviour, is the following:
- Desktop WinForm client application on W2K and .Net 2.0, accessing directly
to an IIS 5.0 site using an "https:" address. Proxy built adding a reference
to the web service.
-[IIS site in local machine] (in principle, this shouldn't matter)
- IIS site configured:
- To accept "Integrated Windows authentication", and
- Without "requiring" SSL, it accepts client certificates
-[IIS site hosting a simple web service developed on .Net 2.0] (in
principle, this shouldn't matter, either)

Behaviour:
- When desktop application is configured to present a client certificate it
works fine. Web service is accesed and the identity it sees comes from the
mapping defined in IIS for that certificate.
(service.ClientCertificates.Add(cert);)
- When desktop application is configured to present kerberos ticket
(integrated security), it times out. (service.Credentials =
CredentialCache.DefaultCredentials;)

Notes:
- When desktop application acceses the web service via "http:" and
integrated security, it also works fine.

Hope this explanation helps. I have been unable read anything that makes me
think this scenario (an IIS site configured to accept both types of
credentials under https:) does not work. Perhaps I should do something else
in the client code, but I have also been unable to find anything regarding
that.

Many thanks again.

JACorona


"David Wang" wrote:

> Windows Integrated Authentication works over HTTPS. Independent of
> Client-Cert mapping.
>
> On which network leg does the network proxy happen? Because Integrated
> Authentication user token cannot be "proxied" downstream by default.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
> On Jan 31, 2:27 am, jacorona
> wrote:
> > Hello all,
> >
> > After spending a few hours searching the web, I post this message to this
> > newsgroup just in case what seems to me an strange behaviour could be due to
> > IIS.
> >
> > I'm trying to access a web service hosted in an IIS site configured to
> > accept both "Integrated Windows authentication" and "client certificates"
> > using an "https:" Uri. The client is a WinForm application in .Net 2.0.
> >
> > When I configure the web service proxy to use client certificates it works
> > OK (the cert is mapped to a Windows account and the web service runs).
> > However, if I configure it to use the integrated Windows credentials, it
> > hangs.
> >
> > Perhaps the .Net proxy configuration is more complex than I suspect, but I
> > post the doubt to this newsgroup just in case that IIS shouldn't be
> > configured that way for any reason. Summarising, should it be possible to
> > access an IIS site thru an "https:" Uri using either Windows integrated
> > authentication or client certificates?
> >
> > Any help will be appreciated. Many thanks.
>
>
>

Re: Unable to authenticate via kerberos to IIS site accepting clie

Hmm... you may be seeing a known problem with IIS5 and
ClientCertificate on large requests. And Kerberos tickets can make
request large.

This is technically a flaw within the SSL specification, and you can
work around it by increasing the size of UploadReadAheadSize to
something larger than the 49152 default (i.e. 102400). You don't want
it too large since that would constitute a DOS security vulnerability.

I know this issue is handled in IIS6, but I do not think it was fixed
in IIS5 - Windows 2000 was already at end of life and no customer
request = no porting. Changing UploadReadAheadSize *may* help on IIS5.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



On Jan 31, 11:46 pm, jacorona
wrote:
> Thank you for answering, David.
>
> The setup to test this strange behaviour, is the following:
> - Desktop WinForm client application on W2K and .Net 2.0, accessing directly
> to an IIS 5.0 site using an "https:" address. Proxy built adding a reference
> to the web service.
> -[IIS site in local machine] (in principle, this shouldn't matter)
> - IIS site configured:
> - To accept "Integrated Windows authentication", and
> - Without "requiring" SSL, it accepts client certificates
> -[IIS site hosting a simple web service developed on .Net 2.0] (in
> principle, this shouldn't matter, either)
>
> Behaviour:
> - When desktop application is configured to present a client certificate it
> works fine. Web service is accesed and the identity it sees comes from the
> mapping defined in IIS for that certificate.
> (service.ClientCertificates.Add(cert);)
> - When desktop application is configured to present kerberos ticket
> (integrated security), it times out. (service.Credentials =
> CredentialCache.DefaultCredentials;)
>
> Notes:
> - When desktop application acceses the web service via "http:" and
> integrated security, it also works fine.
>
> Hope this explanation helps. I have been unable read anything that makes me
> think this scenario (an IIS site configured to accept both types of
> credentials under https:) does not work. Perhaps I should do something else
> in the client code, but I have also been unable to find anything regarding
> that.
>
> Many thanks again.
>
> JACorona
>
>
>
> "David Wang" wrote:
> > Windows Integrated Authentication works over HTTPS. Independent of
> > Client-Cert mapping.
>
> > On which network leg does the network proxy happen? Because Integrated
> > Authentication user token cannot be "proxied" downstream by default.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Jan 31, 2:27 am, jacorona
> > wrote:
> > > Hello all,
>
> > > After spending a few hours searching the web, I post this message to this
> > > newsgroup just in case what seems to me an strange behaviour could be due to
> > > IIS.
>
> > > I'm trying to access a web service hosted in an IIS site configured to
> > > accept both "Integrated Windows authentication" and "client certificates"
> > > using an "https:" Uri. The client is a WinForm application in .Net 2.0.
>
> > > When I configure the web service proxy to use client certificates it works
> > > OK (the cert is mapped to a Windows account and the web service runs).
> > > However, if I configure it to use the integrated Windows credentials, it
> > > hangs.
>
> > > Perhaps the .Net proxy configuration is more complex than I suspect, but I
> > > post the doubt to this newsgroup just in case that IIS shouldn't be
> > > configured that way for any reason. Summarising, should it be possible to
> > > access an IIS site thru an "https:" Uri using either Windows integrated
> > > authentication or client certificates?
>
> > > Any help will be appreciated. Many thanks.- Hide quoted text -
>
> - Show quoted text -

Re: Unable to authenticate via kerberos to IIS site accepting clie

Many thanks again David.

However, I don't think the problem has to do with the size of the request
being too large.
In fact, this is only a test I wrote to check whether there could be any
problem with this aproach and the web service and the method are minimal. I
am only requesting the name of the authenticated user the web service sees.

Incidentally, I have also checked this behaviour on XP SP2 (.Net 2.0 and IIS
5.0) and it works the same; i.e. the client also times out.

I am suspecting that the problem resides on the client part. In fact, if I
access the web service from a browser (requesting the WSDL, for instance) via
https:, after manually dismissing the dialog to select a certificate, it
works fine using integrated security. What o how works IE in this case, so
that one can do the same programmatically?

If you think this could not be the right discussion group, could you please
point me to a more appropiate one?

Many thanks again for your time.


"David Wang" wrote:

> Hmm... you may be seeing a known problem with IIS5 and
> ClientCertificate on large requests. And Kerberos tickets can make
> request large.
>
> This is technically a flaw within the SSL specification, and you can
> work around it by increasing the size of UploadReadAheadSize to
> something larger than the 49152 default (i.e. 102400). You don't want
> it too large since that would constitute a DOS security vulnerability.
>
> I know this issue is handled in IIS6, but I do not think it was fixed
> in IIS5 - Windows 2000 was already at end of life and no customer
> request = no porting. Changing UploadReadAheadSize *may* help on IIS5.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>

Re: Unable to authenticate via kerberos to IIS site accepting clie

I really do not know of a better newsgroup, and I do not believe this
is a client-side issue.

I do not believe you can dismiss my suggestion because your
observations simply do not disprove my point and actually support it
in many cases.

> However, I don't think the problem has to do with the size of
> the request being too large.
> In fact, this is only a test I wrote to check whether there
> could be any problem with this aproach and the web service
> and the method are minimal. I am only requesting the
> name of the authenticated user the web service sees.

The simplicity of the web service and "only requesting the name of the
authenticated user" have no relation to the size of the request. SSL
Client Certificates are negotiated before server even sees the data,
and Kerberos protocol of Integrated Authentication can affect the size
of that encrypted data such that SSL Client Certificates are received
outside of UploadReadAheadSize.

In other words, your actions were insufficient. You need to prove
either:
1. In your failing cases, Integrated Authentication used NTLM and not
Kerberos
2. SSL Certificates are read before UploadReadAheadSize

> Incidentally, I have also checked this behaviour on XP SP2
> (.Net 2.0 and IIS 5.0) and it works the same; i.e. the client
> also times out.

No surprise since XPSP2 runs the same core as IIS5. This really proves
nothing.

> I am suspecting that the problem resides on the client part.
> In fact, if I access the web service from a browser (requesting
> the WSDL, for instance) via https:, after manually dismissing
> the dialog to select a certificate, it works fine using
> integrated security. What o how works IE in this case, so
> that one can do the same programmatically?

When you manually dismiss the dialog to select a certificate, IE does
NOT send a client certificate. This means that the processing of the
SSL Client Certificate is the issue -- which is exactly what I'm
saying.


In other words, I believe your observations support my point. Can you:
1. Confirm that Kerberos is used over Integrated Authentication and
SSL. If this machine is in a domain and you never configure
NTAuthenticationProviders to have NTLM to be default, then you are
using Kerberos
2. Check the size of the Kerberos ticket. Make the same request over
HTTP and with a network sniffer, determine the size of that Kerberos
Authorization: request header

The size of the Kerberos Authorization: header depends on the
authenticated Windows user and their domain membership. You really
cannot control the size of this blob, so there is no way you can
discount it as an issue without directly observing it.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Feb 5, 3:14 am, jacorona
wrote:
> Many thanks again David.
>
> However, I don't think the problem has to do with the size of the request
> being too large.
> In fact, this is only a test I wrote to check whether there could be any
> problem with this aproach and the web service and the method are minimal. I
> am only requesting the name of the authenticated user the web service sees.
>
> Incidentally, I have also checked this behaviour on XP SP2 (.Net 2.0 and IIS
> 5.0) and it works the same; i.e. the client also times out.
>
> I am suspecting that the problem resides on the client part. In fact, if I
> access the web service from a browser (requesting the WSDL, for instance) via
> https:, after manually dismissing the dialog to select a certificate, it
> works fine using integrated security. What o how works IE in this case, so
> that one can do the same programmatically?
>
> If you think this could not be the right discussion group, could you please
> point me to a more appropiate one?
>
> Many thanks again for your time.
>
>
>
> "David Wang" wrote:
> > Hmm... you may be seeing a known problem with IIS5 and
> > ClientCertificate on large requests. And Kerberos tickets can make
> > request large.
>
> > This is technically a flaw within the SSL specification, and you can
> > work around it by increasing the size of UploadReadAheadSize to
> > something larger than the 49152 default (i.e. 102400). You don't want
> > it too large since that would constitute a DOS security vulnerability.
>
> > I know this issue is handled in IIS6, but I do not think it was fixed
> > in IIS5 - Windows 2000 was already at end of life and no customer
> > request = no porting. Changing UploadReadAheadSize *may* help on IIS5.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //- Hide quoted text -
>
> - Show quoted text -

Re: Unable to authenticate via kerberos to IIS site accepting clie

Hello David,
please forgive my delaying in answering your comments.

I have had some time to test your suggestion, but it still doesn't work. The
client program still times out.

I first have made the change in the IIS metabase manually using MetaEdit,
trying to set this parameter (uploadreadaheadsize) in a couple os branches (I
was unsure exactly where to set it) and via script (in this case specifically
in w3svc/1/uploadreadaheadsize). In all the cases the result was the same (I
restarted IIS, etc,...)

Apart from not having read anything that suggested that it shouldn't work,
the fact is that in the same environment (locally in W2K or WXP) when
accessing an .aspx page in the same directory via IE, and after dismissing
the dialog for selecting a certificate, IE accesses the page with integrated
credentials. What I don't know is what IE does programmatically.

As an aside, do you know of any debugging tool that let you inspect an https
communication (in case it were possible, obviously providing it first with
any needed certificate).

Thank you for your help.
Alfonso Corona


"David Wang" wrote:

> I really do not know of a better newsgroup, and I do not believe this
> is a client-side issue.
>
> I do not believe you can dismiss my suggestion because your
> observations simply do not disprove my point and actually support it
> in many cases.
>
> > However, I don't think the problem has to do with the size of
> > the request being too large.
> > In fact, this is only a test I wrote to check whether there
> > could be any problem with this aproach and the web service
> > and the method are minimal. I am only requesting the
> > name of the authenticated user the web service sees.
>
> The simplicity of the web service and "only requesting the name of the
> authenticated user" have no relation to the size of the request. SSL
> Client Certificates are negotiated before server even sees the data,
> and Kerberos protocol of Integrated Authentication can affect the size
> of that encrypted data such that SSL Client Certificates are received
> outside of UploadReadAheadSize.
>
> In other words, your actions were insufficient. You need to prove
> either:
> 1. In your failing cases, Integrated Authentication used NTLM and not
> Kerberos
> 2. SSL Certificates are read before UploadReadAheadSize
>
> > Incidentally, I have also checked this behaviour on XP SP2
> > (.Net 2.0 and IIS 5.0) and it works the same; i.e. the client
> > also times out.
>
> No surprise since XPSP2 runs the same core as IIS5. This really proves
> nothing.
>
> > I am suspecting that the problem resides on the client part.
> > In fact, if I access the web service from a browser (requesting
> > the WSDL, for instance) via https:, after manually dismissing
> > the dialog to select a certificate, it works fine using
> > integrated security. What o how works IE in this case, so
> > that one can do the same programmatically?
>
> When you manually dismiss the dialog to select a certificate, IE does
> NOT send a client certificate. This means that the processing of the
> SSL Client Certificate is the issue -- which is exactly what I'm
> saying.
>
>
> In other words, I believe your observations support my point. Can you:
> 1. Confirm that Kerberos is used over Integrated Authentication and
> SSL. If this machine is in a domain and you never configure
> NTAuthenticationProviders to have NTLM to be default, then you are
> using Kerberos
> 2. Check the size of the Kerberos ticket. Make the same request over
> HTTP and with a network sniffer, determine the size of that Kerberos
> Authorization: request header
>
> The size of the Kerberos Authorization: header depends on the
> authenticated Windows user and their domain membership. You really
> cannot control the size of this blob, so there is no way you can
> discount it as an issue without directly observing it.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
> On Feb 5, 3:14 am, jacorona
> wrote:
> > Many thanks again David.
> >
> > However, I don't think the problem has to do with the size of the request
> > being too large.
> > In fact, this is only a test I wrote to check whether there could be any
> > problem with this aproach and the web service and the method are minimal. I
> > am only requesting the name of the authenticated user the web service sees.
> >
> > Incidentally, I have also checked this behaviour on XP SP2 (.Net 2.0 and IIS
> > 5.0) and it works the same; i.e. the client also times out.
> >
> > I am suspecting that the problem resides on the client part. In fact, if I
> > access the web service from a browser (requesting the WSDL, for instance) via
> > https:, after manually dismissing the dialog to select a certificate, it
> > works fine using integrated security. What o how works IE in this case, so
> > that one can do the same programmatically?
> >
> > If you think this could not be the right discussion group, could you please
> > point me to a more appropiate one?
> >
> > Many thanks again for your time.
> >
> >
> >
> > "David Wang" wrote:
> > > Hmm... you may be seeing a known problem with IIS5 and
> > > ClientCertificate on large requests. And Kerberos tickets can make
> > > request large.
> >
> > > This is technically a flaw within the SSL specification, and you can
> > > work around it by increasing the size of UploadReadAheadSize to
> > > something larger than the 49152 default (i.e. 102400). You don't want
> > > it too large since that would constitute a DOS security vulnerability.
> >
> > > I know this issue is handled in IIS6, but I do not think it was fixed
> > > in IIS5 - Windows 2000 was already at end of life and no customer
> > > request = no porting. Changing UploadReadAheadSize *may* help on IIS5.
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //- Hide quoted text -
> >
> > - Show quoted text -
>
>
>

Re: Unable to authenticate via kerberos to IIS site accepting clie

Can you please first answer my prior questions so that we can make
forward progress.
1. In the failing case, is it Kerberos over SSL Client Certificate.
and NOT NTLM over SSL CLient Certificate
2. If it is Kerberos, determine the size of the ticket blob in the
request header. You can do this test over HTTP to sniff the traffic

In general, I recommend *against* making changes without making the
diagnosis first, and changes to UploadReadAheadSize on IIS5 has no
affect on what I suspect to be the issue and has other consequences...
so I suggest you *revert* your changes.

Do not make changes before diagnosing the issue. How would you feel if
your physician first performs open heart surgery on you and then looks
at your blood sample.

IE is not doing anything "special" when you dismiss the Client Cert
selection dialog - just Integrated Authentication without Client
Certificates, which we know works. But, that is NOT what you want -
Kerberos over Client Certificates - so please do not get distracted.

IFF the issue is large Kerberos ticket over SSL Client Certificate,
then:
1. there is no solution on IIS5/IIS5.1 (UploadReadAheadSize does not
work)
2. You will need IIS6 on Windows Server 2003 and change
UploadReadAheadSize, as documented
3. Or make your Kerberos ticket smaller.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Feb 15, 12:51 am, jacorona
wrote:
> Hello David,
> please forgive my delaying in answering your comments.
>
> I have had some time to test your suggestion, but it still doesn't work. The
> client program still times out.
>
> I first have made the change in the IIS metabase manually using MetaEdit,
> trying to set this parameter (uploadreadaheadsize) in a couple os branches (I
> was unsure exactly where to set it) and via script (in this case specifically
> in w3svc/1/uploadreadaheadsize). In all the cases the result was the same (I
> restarted IIS, etc,...)
>
> Apart from not having read anything that suggested that it shouldn't work,
> the fact is that in the same environment (locally in W2K or WXP) when
> accessing an .aspx page in the same directory via IE, and after dismissing
> the dialog for selecting a certificate, IE accesses the page with integrated
> credentials. What I don't know is what IE does programmatically.
>
> As an aside, do you know of any debugging tool that let you inspect an https
> communication (in case it were possible, obviously providing it first with
> any needed certificate).
>
> Thank you for your help.
> Alfonso Corona
>
>
>
> "David Wang" wrote:
> > I really do not know of a better newsgroup, and I do not believe this
> > is a client-side issue.
>
> > I do not believe you can dismiss my suggestion because your
> > observations simply do not disprove my point and actually support it
> > in many cases.
>
> > > However, I don't think the problem has to do with the size of
> > > the request being too large.
> > > In fact, this is only a test I wrote to check whether there
> > > could be any problem with this aproach and the web service
> > > and the method are minimal. I am only requesting the
> > > name of the authenticated user the web service sees.
>
> > The simplicity of the web service and "only requesting the name of the
> > authenticated user" have no relation to the size of the request. SSL
> > Client Certificates are negotiated before server even sees the data,
> > and Kerberos protocol of Integrated Authentication can affect the size
> > of that encrypted data such that SSL Client Certificates are received
> > outside of UploadReadAheadSize.
>
> > In other words, your actions were insufficient. You need to prove
> > either:
> > 1. In your failing cases, Integrated Authentication used NTLM and not
> > Kerberos
> > 2. SSL Certificates are read before UploadReadAheadSize
>
> > > Incidentally, I have also checked this behaviour on XP SP2
> > > (.Net 2.0 and IIS 5.0) and it works the same; i.e. the client
> > > also times out.
>
> > No surprise since XPSP2 runs the same core as IIS5. This really proves
> > nothing.
>
> > > I am suspecting that the problem resides on the client part.
> > > In fact, if I access the web service from a browser (requesting
> > > the WSDL, for instance) via https:, after manually dismissing
> > > the dialog to select a certificate, it works fine using
> > > integrated security. What o how works IE in this case, so
> > > that one can do the same programmatically?
>
> > When you manually dismiss the dialog to select a certificate, IE does
> > NOT send a client certificate. This means that the processing of the
> > SSL Client Certificate is the issue -- which is exactly what I'm
> > saying.
>
> > In other words, I believe your observations support my point. Can you:
> > 1. Confirm that Kerberos is used over Integrated Authentication and
> > SSL. If this machine is in a domain and you never configure
> > NTAuthenticationProviders to have NTLM to be default, then you are
> > using Kerberos
> > 2. Check the size of the Kerberos ticket. Make the same request over
> > HTTP and with a network sniffer, determine the size of that Kerberos
> > Authorization: request header
>
> > The size of the Kerberos Authorization: header depends on the
> > authenticated Windows user and their domain membership. You really
> > cannot control the size of this blob, so there is no way you can
> > discount it as an issue without directly observing it.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Feb 5, 3:14 am, jacorona
> > wrote:
> > > Many thanks again David.
>
> > > However, I don't think the problem has to do with the size of the request
> > > being too large.
> > > In fact, this is only a test I wrote to check whether there could be any
> > > problem with this aproach and the web service and the method are minimal. I
> > > am only requesting the name of the authenticated user the web service sees.
>
> > > Incidentally, I have also checked this behaviour on XP SP2 (.Net 2.0 and IIS
> > > 5.0) and it works the same; i.e. the client also times out.
>
> > > I am suspecting that the problem resides on the client part. In fact, if I
> > > access the web service from a browser (requesting the WSDL, for instance) via
> > > https:, after manually dismissing the dialog to select a certificate, it
> > > works fine using integrated security. What o how works IE in this case, so
> > > that one can do the same programmatically?
>
> > > If you think this could not be the right discussion group, could you please
> > > point me to a more appropiate one?
>
> > > Many thanks again for your time.
>
> > > "David Wang" wrote:
> > > > Hmm... you may be seeing a known problem with IIS5 and
> > > > ClientCertificate on large requests. And Kerberos tickets can make
> > > > request large.
>
> > > > This is technically a flaw within the SSL specification, and you can
> > > > work around it by increasing the size of UploadReadAheadSize to
> > > > something larger than the 49152 default (i.e. 102400). You don't want
> > > > it too large since that would constitute a DOS security vulnerability.
>
> > > > I know this issue is handled in IIS6, but I do not think it was fixed
> > > > in IIS5 - Windows 2000 was already at end of life and no customer
> > > > request = no porting. Changing UploadReadAheadSize *may* help on IIS5.
>
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -