Did you post to the WSUS Newsgroup?
http://www.microsoft.com/technet/com...pdate_services
--
====================================
TaurArian [MS-MVP] 2005-2007 - Australia
====================================
How to make a good post:
http://www.dts-l.org/goodpost.htm
Backup and data recovery:
http://www.acronis.com/
Enhancing file system performance:
http://www.diskeeper.com/defrag.asp
"Paul Sharp" <USENET AT (REMOVE TO REPLY) PSHARP DOT NET> wrote in message
news:45a7fb54$0$8713$...
| (WSUS - Windows Server Update Service / BITS - Background Intelligent
| Transfer Service)
|
| Please apply your collective brains to the following problem...
|
| I have installed WSUS into a Win2K SP4 environment. This is to replace a
| previous SUS installation. SUS worked without any issues. However, after
| installing WSUS (and BITS 2), WSUS cannot synchronise to the Microsoft
| update site through our proxy server.
|
| Having done some investigation, the proxy requires NTLM authentication. If I
| set the proxy to require either anonymous or basic authentication for test
| purposes then synchronisation works. However, our security policy requires
| NTLM.
|
| The credentials used for authentication are a domain user account,
| configured in the WSUS Admin Synchronisation page. However, synchronisation
| attempts fail with a '407 - Authentication Required' response from the
| Proxy.
|
| As stated, the previous SUS installation did not have this problem. Also, if
| I log on interactively to any domain host with this domain account and
| launch Internet Explorer, IE will successfully authenticate to the proxy via
| NTLM. The problem only seems to affect WSUS (or perhaps BITS?)
|
| Running a LAN trace, I can see that initially the WSUS server tries to
| CONNECT anonymously, resulting in an initial 407 response from the proxy,
| specifying NTLM as the accepted authentication method.
|
| WSUS then sends another CONNECT request with a Type 1 base64 encoded NTLM
| string in the HTTP header.
| Proxy sends another 407 response with a Type 2 NTLM challenge in the HTTP
| header
| WSUS then sends a Type 3 NTLM message back to the proxy
|
| So far the above is what I would expect, but finally the Proxy sends yet
| another 407 Authentication Message back, this time including the HTML error
| page that would be displayed in a web browser at this point.
|
| This whole communication takes place over HTTP 1.1. WSUS always uses
| persistent connections, but Proxy always sets the Connection: Close header
| in the HTTP response, so the TCP session is always torn down and
| re-initiated between each WSUS/Proxy HTTP exchange. I am not sure this is
| correct. I have read that the NTLM exchange needs to take place over a
| persistent connection over HTTTP 1.1 (or using keep alives over HTTP 1.0).
| But I do not believe that the Proxy is at fault because SUS and IE (and
| anything else, including our Anti Virus updater) authenticate without any
| issues.
|
| I've run out of ideas now as to what may be going on. I've even decoded the
| Base64 NTLM strings from the HTTP packets, and as best I can tell they have
| the correct Type 1, 2 & 3 flags set respectively and contain the correct
| domain, host and user information where required.
|
| The proxy in question is Clearswift Mimesweeper for Web.
|
| I have seen lots of people when trawling Google that are having 407
| authentication issues with WSUS and proxy servers, but have not found a
| definitive solution. I found an article on Microsoft's site that suggests
| that BITS 2 can have issues with NTLM authentication, but again I am not
| clear on what the solution is. I have tried using the Local Security Policy
| on both the WSUS and Proxy servers to disable the sending of LM messages
| during NTLM authentication, but this does not appear to make any
| differences.
|
| Can anybody suggest where I go next, or has anybody actually discovered the
| solution to this problem?
|
| Any help would be very much appreciated.
|
| TIA
|
| Paul
|
|
Similar Threads
Linear Mode
