« Previous Next »

Thread: Using MWA to remotely manage IIS on Server Core.

Last post 05-27-2008 10:48 AM by mvolo. 20 replies.

Average Rating Rate It (5)

RSS

Page 2 of 2 (21 items) < Previous 1 2

Sort Posts:

  • 01-27-2008, 12:45 PM In reply to

    Re: Using MWA to remotely manage IIS on Server Core.

    Colin 

    Thanks much!

    I confirm that adding those two rules work for MWA! You rock!

    The starnge thing is that MWA works right away agaisnt IIS7 installed on a full server ( without any modification for the firewall rules) while it's quite a challenge to find out rules for MWA on Server Core.

    Again, thanks for looking at this problem,

    /Dung

     

  • 01-27-2008, 1:16 PM In reply to

    • colinbo
    • Top 100 Contributor
    • Joined on 10-22-2003, 3:36 PM
    • Toronto, Canada
    • Posts 53

    Re: Using MWA to remotely manage IIS on Server Core.

    DungKHoang:
    Proto                     Local Address                   Foreign Address                                         State
    TCP                      192.168.0.111:135             192.168.0.110:49228                                  ESTABLISHED
    RpcSs
    [Svchost.exe]

    Netstat is a timing-based tool.  You need to get it at the right time to see the connection to the end-point established.  The excerpt above is probably too early in the process since the connection is being made to the RPC endpoint mapper.  Windows Server 2008 has changed the RPC endpoint mapper behaviour from using all ports above 1024 for dynamic endpoints to locking it down to a specific range of 49152 through 65535 by default.  This should eliminate the need for setting the RPC registry key you noted allowing you to focus on 49152 and above.

     I mentioned the SvcHost earlier because it appears that Windows Firewall will automagically read into the RPC packet and look for the end point service that is being accessed to provide another level of filtering beyond a port number.  This is pretty nifty in my opinion.  The resulting Windows Firewall rules then say that "i'm going to allow dynamic RPC endpoint traffic, but it must be service X that is being access".  This is certainly one step better than opening up an entire port range into the open.  Too bad it doesn't support DLLHost-based processes which is why I suggested that SvcHost.exe is a better choice, and the best choice being a custom COM surrogate wrapper.  Other approaches have been to lock services down to specific endpoints.  NTDS, Netlogon, and FRS take this approach.  I don't really have a preference either way from a development perspective, but I know the security folks do prefer a known ports rather than a range.  I'm also going to suggest that it is unlikely that you'll have many happy security analysts who want to open 49152-65535 for servers because it relies on the server being properly configured as well.  The trust factor will make this a nightmare scenario that could easily be solved by enabling adminsitrators to set a specific port.  I don't know the underpinings well enough to comment on the best approach but I do know that DCOM does offer up the ability to lock down to a specific port through Component Services.

    Thanks for the post too, it has been interesting to dig back into RPC and get up to speed on some of the smaller changes coming in Windows Server 2008.  These changes make it exciting and worth to upgrade to the latest versions.  I'm excited to get our hands on the advanced firewall for our production servers next month.  I wrote up more of an explanation on how I understand RPC to work for others that come across this thread in the future.

    Cheers,
    Colin

    Blog: http://colin.rockstarguys.com
    ---
    When you ask a question, remember to click "mark as answered" when you get a reply which answers your question; this ensures the member gets credit below for being helpful.
  • 01-27-2008, 10:20 PM In reply to

    • mvolo
    • Top 25 Contributor
    • Joined on 09-17-2003, 1:48 PM
    • Philadelphia, PA
    • Posts 584
    • IIS MVPs

    Re: Using MWA to remotely manage IIS on Server Core.

    Dan, Colin,

    I've asked our config guys to look into producing official guidance for opening up DCOM for the configuration COM objects.

    IMHO, I wouldnt open RPC in general in a production system just to allow MWA remoting - I believe many enterprises already have policy against doing this. Opening RPC for dllhost.exe is no better (as Colin mentions), since most COM objects are hosted by dllhost.exe COM servers.

    Given the current DCOM support, I would use the approach given by KB 312960 to publish the RPC endpoint used by the "Ahadmin" COM package to a specific port. Then, open that port in the firewall.  This way, you would only open DCOM access to the IIS COM objects, which require authentication and demand administrative credentials.

    Also, while this is not a substitute for programatic IIS administration, you can consider using IIS Manager's remote management capability which uses HTTP-based connectivity to the management service, and therefore doesnt require DCOM. Unfortunately, this currently requires you to perform your management within the context of the IIS Manager.

    I've asked our config guys to come up with the official guidance for opening DCOM endpoints for Ahadmin that can be published on IIS.NET.

    Thanks for raising this issue -

    Mike Volodarsky

    Program Manager
    IIS Core Server
    Visit mvolo.com for more on IIS 7.0 and ASP.NET

    This posting is provided "AS IS" with no warranties, and confers no rights.
  • 01-27-2008, 11:38 PM In reply to

    • colinbo
    • Top 100 Contributor
    • Joined on 10-22-2003, 3:36 PM
    • Toronto, Canada
    • Posts 53

    Re: Using MWA to remotely manage IIS on Server Core.

    Mike,

    I agree that the dllhost.exe is a pretty nasty solution.  The key though is the AHAdmin COM object.  With that information I added an Endpoints entry to the registry per KB217351, rebooted the server, and now my server is happy with a locked down port.  My new rule set is as follows:

    NetSh AdvFirewall Firewall Add Rule Name="Remote Web Server Management (RPC)" Dir=In Action=Allow Program="C:\WINDOWS\SYSTEM32\dllhost.exe" Protocol=TCP LocalPort=49494

    NetSh AdvFirewall Firewall Add Rule Name="Remote Web Server Management (RPC-EPMap)" Dir=In Action=Allow Program="C:\WINDOWS\SYSTEM32\SvcHost.exe" Service=RPCSS Protocol=TCP LocalPort=RPC-EPMap

    That's a whole lot more secure.  I would love to use the IIS Management Service but my understanding is that with Server Core that is not an option.  Hopefully the Server Core guys will get the .NET Framework in for the next release.  I can see a lot of advantages to having it as an option in Server Core.

    Cheers,
    Colin

    Blog: http://colin.rockstarguys.com
    ---
    When you ask a question, remember to click "mark as answered" when you get a reply which answers your question; this ensures the member gets credit below for being helpful.
  • 03-08-2008, 1:07 AM In reply to

    • colinbo
    • Top 100 Contributor
    • Joined on 10-22-2003, 3:36 PM
    • Toronto, Canada
    • Posts 53

    Re: Using MWA to remotely manage IIS on Server Core.

    mvolo:
    I've asked our config guys to look into producing official guidance for opening up DCOM for the configuration COM objects

     

    Mike - Did this guidance get published? 

    Blog: http://colin.rockstarguys.com
    ---
    When you ask a question, remember to click "mark as answered" when you get a reply which answers your question; this ensures the member gets credit below for being helpful.
  • 05-27-2008, 10:48 AM In reply to

    • mvolo
    • Top 25 Contributor
    • Joined on 09-17-2003, 1:48 PM
    • Philadelphia, PA
    • Posts 584
    • IIS MVPs

    Re: Using MWA to remotely manage IIS on Server Core.

    Update on this:

    In the absence of an official article, I describe the fixed port best practice here: http://mvolo.com/blogs/serverside/archive/2008/05/26/Accessing-IIS-7.0-configuration-remotely-and-on-server-core.aspx.

    There is a batch file to configure fixed port access, and a tool you can use to check common connectivity issues.

    Thanks,

    Mike Volodarsky

    http://www.mvolo.com

    This posting is provided "AS IS" with no warranties, and confers no rights.
Page 2 of 2 (21 items) < Previous 1 2
Microsoft Communities