locked
Make WSUS accessible over the web RRS feed

  • Question

  • We're in the process of deploying WSUS on Windows 2012 R2 in our environment and I have a question regarding access over the web...  I would  like to provide clients with the ability to access the update server regardless of being connected to the company internal network.  I see that the standard GPO settings call for following, and in our lab it is working fine.  One the same internal network.

    Computer Configuration, Policies, Administrative Templates, Windows Components, Windows Update

    Specify intranet Microsoft update service location

    Set the intranet update service for detection updates: http://serverhostname:5830

    Set the intranet statistics server: http://serverhostname:5830

    So, If I wanted to change this to HTTPS and make it accessible over the web, based on my experience with Windows Server the steps would look something like this:

    1. Create Internal and external DNS record that will resolve the internal IP address of the WSUS server and the External IP address of the WSUS server.  wsus.domain.com for example.

    2. Purchase a Godaddy or competing certificate from a public store and install it for the default site in IIS. Configure HTTPS bindings to answer on port 5830.

    3. Configure GPO mentioned above to utilize https://wsus.domain.com:5830

    ~~~~~~~~~~~~~~~~~

    Seems pretty straight forward.. However I am wondering if this configuration is supported, recommended, or if anyone else out there has it configured in this way? Our deployment will service approximately 300 workstations from a single installation at our datacenter. Any insight or recommendations would be greatly appreciated. Thank you!

    Adam Tyler / adam@tylercrew.com

    Friday, August 8, 2014 4:58 PM

Answers

  • Specify intranet Microsoft update service location

    Set the intranet update service for detection updates: http://serverhostname:5830

    Set the intranet statistics server: http://serverhostname:5830

    Actually it's port 8530.

    So, If I wanted to change this to HTTPS and make it accessible over the web, based on my experience with Windows Server the steps would look something like this:

    1. Create Internal and external DNS record that will resolve the internal IP address of the WSUS server and the External IP address of the WSUS server.  wsus.domain.com for example.

    2. Purchase a Godaddy or competing certificate from a public store and install it for the default site in IIS. Configure HTTPS bindings to answer on port 5830.

    3. Configure GPO mentioned above to utilize https://wsus.domain.com:5830

    ~~~~~~~~~~~~~~~~~

    Seems pretty straight forward..

    That part is, yes. :)

    However I am wondering if this configuration is supported, recommended, or if anyone else out there has it configured in this way?

    It's not supported. It's not recommended, as described, although you're well on your way. And, the real kicker.. strictly speaking, it's not licensed for use in that manner. Let me e'splain why.

    The licensing for WSUS restricts its use to only clients that are licensed to the entity operating the WSUS server. As such client identity is a key component of strict licensing compliance.

    While Server-Side SSL certainly ensures the client only connects to an authorized server, it does not identify the client, nor restrict the client by known identity, and it wouldn't even prevent an unauthorized client from accessing that server -- all that's needed is a copy of the CER. So there's that, which is probably not a deal killer, even considering the strictest interpretation of the licensing, because the risk is fairly low, and MS really isn't going to chase you down because you *might* be capable of offering services to unlicensed client systems.

    Here's the real risk: Access to the SSL certificate would also permit a rogue downstream server to dump your complete collection of updates, groups, and approvals to itself, effectively giving the operator of that rogue server information about what security updates are approved, and when they were approved, but also which updates are NOT approved -- which offers up some sensitive information about existing vulnerabilities in those workstations. In effect, security of the public certificate becomes paramount.

    More significantly, someone using the API can dig out even more sensitive information about client computers, actual installations, etc. without even setting up a WSUS server, all they need is a working API installation (which can be done on any desktop operating system).

    SSL is definitely the minimum requirement for this type of deployment, but in conjunction with making the client services available via SSL, you'll also want to BLOCK access to /DssAuthWebService, /ServerSyncWebService, and /ApiRemoting30 via the firewall. Blocking /ApiRemoting30 is fairly straightforward as it requires an authenticated connection anyway, so mostly that's a matter of properly securing the server logons, but downstream server sync is anonymous by default, so you'll want to configure required authentication for downstream servers. You won't have any, of course, but that will also preclude the possibility of any. Configuring DSS Authentication is discussed in the WSUS Deployment Guide in TechNet.

    Having said all of that, the conventional way in which WSUS services have been made available to Internet-based clients is via VPN using a replica server without a content store. VPN-based clients get approvals from the replica WSUS server, but then download content direct from Microsoft. Client installs updates when downloads are complete.

    VPN is a headache for a lot of orgs, though, and it requires active participation on the part of the computer user, which sometimes impedes successful deployment of updates in a timely manner.

    The ideal methodology, but also a PITA to set up, would be to access that WSUS server via an IPSec-encrypted Direct Access connection. This eliminates the end-user from the process, and ensures client identity through IPSec/DA authentication.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.


    Friday, August 8, 2014 9:59 PM

All replies

  • Specify intranet Microsoft update service location

    Set the intranet update service for detection updates: http://serverhostname:5830

    Set the intranet statistics server: http://serverhostname:5830

    Actually it's port 8530.

    So, If I wanted to change this to HTTPS and make it accessible over the web, based on my experience with Windows Server the steps would look something like this:

    1. Create Internal and external DNS record that will resolve the internal IP address of the WSUS server and the External IP address of the WSUS server.  wsus.domain.com for example.

    2. Purchase a Godaddy or competing certificate from a public store and install it for the default site in IIS. Configure HTTPS bindings to answer on port 5830.

    3. Configure GPO mentioned above to utilize https://wsus.domain.com:5830

    ~~~~~~~~~~~~~~~~~

    Seems pretty straight forward..

    That part is, yes. :)

    However I am wondering if this configuration is supported, recommended, or if anyone else out there has it configured in this way?

    It's not supported. It's not recommended, as described, although you're well on your way. And, the real kicker.. strictly speaking, it's not licensed for use in that manner. Let me e'splain why.

    The licensing for WSUS restricts its use to only clients that are licensed to the entity operating the WSUS server. As such client identity is a key component of strict licensing compliance.

    While Server-Side SSL certainly ensures the client only connects to an authorized server, it does not identify the client, nor restrict the client by known identity, and it wouldn't even prevent an unauthorized client from accessing that server -- all that's needed is a copy of the CER. So there's that, which is probably not a deal killer, even considering the strictest interpretation of the licensing, because the risk is fairly low, and MS really isn't going to chase you down because you *might* be capable of offering services to unlicensed client systems.

    Here's the real risk: Access to the SSL certificate would also permit a rogue downstream server to dump your complete collection of updates, groups, and approvals to itself, effectively giving the operator of that rogue server information about what security updates are approved, and when they were approved, but also which updates are NOT approved -- which offers up some sensitive information about existing vulnerabilities in those workstations. In effect, security of the public certificate becomes paramount.

    More significantly, someone using the API can dig out even more sensitive information about client computers, actual installations, etc. without even setting up a WSUS server, all they need is a working API installation (which can be done on any desktop operating system).

    SSL is definitely the minimum requirement for this type of deployment, but in conjunction with making the client services available via SSL, you'll also want to BLOCK access to /DssAuthWebService, /ServerSyncWebService, and /ApiRemoting30 via the firewall. Blocking /ApiRemoting30 is fairly straightforward as it requires an authenticated connection anyway, so mostly that's a matter of properly securing the server logons, but downstream server sync is anonymous by default, so you'll want to configure required authentication for downstream servers. You won't have any, of course, but that will also preclude the possibility of any. Configuring DSS Authentication is discussed in the WSUS Deployment Guide in TechNet.

    Having said all of that, the conventional way in which WSUS services have been made available to Internet-based clients is via VPN using a replica server without a content store. VPN-based clients get approvals from the replica WSUS server, but then download content direct from Microsoft. Client installs updates when downloads are complete.

    VPN is a headache for a lot of orgs, though, and it requires active participation on the part of the computer user, which sometimes impedes successful deployment of updates in a timely manner.

    The ideal methodology, but also a PITA to set up, would be to access that WSUS server via an IPSec-encrypted Direct Access connection. This eliminates the end-user from the process, and ensures client identity through IPSec/DA authentication.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.


    Friday, August 8, 2014 9:59 PM
  • Lawrence,

    Thanks for your reply.  The show stopper in my opinion was your final couple of paragraphs regarding VPN and the involvement of the end user.  I have yet to work through a Direct Access configuration, but it looks like an "always on" VPN solutions like that may be the best option.  We are using a dedicated 3rd party VPN appliance today.  Can you recommend any good walk through blogs for Direct Access?

    Thanks again.

    Regards,

    Adam Tyler

    adam@tylercrew.com

    Monday, August 18, 2014 6:31 PM
  • Can you recommend any good walk through blogs for Direct Access?

    Not personally, but there's a pretty good primer in Mitch Tulloch's Intro to Windows Server 2012 book, and a web search on "directaccess site:technet.microsoft.com" sure looks like a great place to start. ;)

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Monday, August 18, 2014 11:41 PM