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 <jacor...@xxxxxxxxxxxxxxxxxxxxxxxxx>
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 -



.

Relevant Pages