|
|
You're in the
iis security
group:Unable to authenticate via kerberos to IIS site accepting client c
iis security:
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.
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 <jacor...@discussions.microsoft.com> [quoted text, click to view] 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.
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 [quoted text, click to view] "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 <jacor...@discussions.microsoft.com> > 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. > >
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 <jacor...@discussions.microsoft.com> [quoted text, click to view] 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 <jacor...@discussions.microsoft.com> > > 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 -
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. [quoted text, click to view] "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 > // >
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. [quoted text, click to view] > 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 [quoted text, click to view] > 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. [quoted text, click to view] > 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...@discussions.microsoft.com> [quoted text, click to view] 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 -
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 [quoted text, click to view] "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...@discussions.microsoft.com> > 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 - > >
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 <jacor...@discussions.microsoft.com> [quoted text, click to view] 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 <jacor...@discussions.microsoft.com> > > 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
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |