Partager via

Configuring HTTP for Windows Vista

  • Article

One of the major changes in Windows Vista security is that most people are no longer going to be running with Administrator privileges by default like they were doing on earlier platforms. This impacts your ability to run HTTP web services because listening at a particular HTTP address is a restricted operation. By default, every HTTP path is reserved for use by the system administrator. Your services will fail to start with an AddressAccessDeniedException if you aren't running the service from an elevated account. Windows 2003 includes a tool called httpcfg.exe that lets the owner of an HTTP namespace delegate that ownership to another user. On Windows Vista, httpcfg.exe is no longer included and instead there's a new command set available through netsh.exe.

I'm going to walk through delegating part of the HTTP namespace to get a web service working that wants to listen at localhost:8000/. Since I'm not running as the Administrator when debugging in Visual Studio, the service fails to start when I run it.

 HTTP could not register URL +:8000/. Your process does not have access rights to 
this namespace (see go.microsoft.com/fwlink/?LinkId=70353 for details).

The plus sign in the URL just means that there's a wildcard being applied to the hostname. I'll have another article that talks about wildcards in more detail. To fix this problem, I first need to start a command prompt using "Run as administrator" so that I have elevated privileges. Then, I can use netsh.exe to give some of the Administrator's HTTP namespace to my user account. You can look at the existing HTTP namespace delegations by using "netsh http show urlacl". There should be several namespaces set up by default, including the default one that WCF uses for temporary addresses as an example.

 Reserved URL            : +:80/Temporary_Listen_Addresses/
    User: \Everyone
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;WD)

Now, I'm going to use "netsh http add urlacl url=+:8000/ user=MYMACHINE\UserName" to assign some of the HTTP namespace to my user account. You can get the syntax for all of these commands by running "netsh http" without any arguments. Note that I've matched the URL in this command to the URL that appeared in the error message. The wildcarding is important for getting the right reservation and you'll continue to be denied access if your reservation covers less than your service's attempted registration. Going back to Visual Studio, my service now starts up and runs as expected.

For more details on netsh options, see the article on namespace reservation permissions.

Next time: TransportWithMessageCredential Over TCP

Comments

  • Anonymous
    October 16, 2006
    myITforum Daily Newsletter Daily Newsletter October 16, 2006 The myITforum.com newsletter is delivered

  • Anonymous
    October 16, 2006
    Hang on ... where and at what layer is this check performed? Does this mean that the user can't open a socket to listen on at port 8000 (or any other port?) and that this is enforced by the kernel? Or is the check performed by the web service process in userspace? In which case, what's to stop the user from either evading the check (copying the binary and patching it?) or just installing a different web server (apache?) to run the service from? Or writing their own? (Yes, a home-written one probably won't be fast, or stable, or scale very well, or be as extensible as IIS, or be usable as a transparent proxy, or.... but if it only needs to do one particular job....) Can you at least clarify "listening at a particular HTTP address"? I get listening on a TCP/IP port/address pair. I also get using HTTP over TCP/IP. But I don't see how an HTTP "address" is different from any other TCP/IP address. Very confused.

  • Anonymous
    October 16, 2006
    I have a long-running service operation that needs to receive a response. What options do I have for

  • Anonymous
    October 16, 2006
    HTTP.sys is a kernel device driver for processing HTTP connections on XP SP2 and later.  Besides doing a lot of work for you, it also allows multiple applications to share the same TCP port.  You can configure the IP addresses and ports that HTTP.sys listens on.  Many pieces of Winodws (WCF, IIS 6 and later) are built on top of HTTP.sys.

  • Anonymous
    October 16, 2006
    Device driver? Huh? What device? Or does "device driver" == "kernel module"? You guys put an HTTP server in the kernel? Blech! :) How do multiple apps share the same TCP port? The best documentation I found on http.sys was http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a2a45c42-38bc-464c-a097-d7a202092a54.mspx?mfr=true but it seems a little light on technical details. Is there anything more involved that you know of? If not, does this port-sharing work for any TCP port, or only ones with HTTP running over the top? Also, why would you want multiple apps on the same port? What's wrong with running different apps on different ports?

  • Anonymous
    October 16, 2006
    HTTP.sys is a protocol driver for HTTP traffic in the same sense that TCPIP.sys is a protocol driver for IP traffic.  HTTP.sys handles incoming connections on the TCP port and dispatches to applications based on the path in the HTTP request.  This lets me host http://mymachine/myapp1/ in IIS using ASMX and at the same time host http://mymachine/myapp2/ in WCF.  Businesses can have hundreds or even thousands of applications hosted on a single machine like this without opening every port in their firewall.

  • Anonymous
    October 16, 2006
    This is something I've never understood. What's wrong with opening ports in your firewall. If you have myapp1 running on port 8000 and myapp2 on port 8001, what disadvantage is there doing that over running them both on port 8000, or port 80? I can see plenty of advantages. Such as being able to use the firewall to limit source IPs that can connect to myapp1 while leaving myapp2 open to the world. Such as being able to move myapp1 to a different server and use destination NAT/port forwarding to make it transparent. The whole point of TCP ports is to allow multiple applications to run on a single interface. Why reinvent that as part of the HTTP namespace?

  • Anonymous
    October 17, 2006
    There is so much I want to say about important topics like Rocky's well-written, thought provoking Semantic

  • Anonymous
    October 18, 2006
    The comment has been removed

  • Anonymous
    October 18, 2006
    The comment has been removed

  • Anonymous
    November 01, 2006
    This article covers some of the advanced topics that I left out of the earlier piece on configuring HTTP

  • Anonymous
    December 19, 2006
    I deployed my first WCF service as a Windows Service today. It wasn't as straight forward as I...

  • Anonymous
    January 03, 2007
    I started this blog back in February hoping to produce a daily post throughout the entire month. I had

  • Anonymous
    January 09, 2007
    Hosting a WCF service on a HTTP endpoint on Windows Vista has some issues given that you are not running

  • Anonymous
    May 04, 2007
    A while back, when I was first doing WCF development I ran into the following exception: AddressAccessDeniedException

  • Anonymous
    September 07, 2007
    I want to run this post as a reminder to people building and deploying services. I see people deploy

  • Anonymous
    September 24, 2007
    There is so much I want to say about important topics like Rocky's well-written, thought provoking

  • Anonymous
    July 28, 2008
    Enabling HttpListeners for Non-Admins

  • Anonymous
    May 14, 2009
    #.think.in infoDose #28 (29th Apr - 8th May)

  • Anonymous
    May 30, 2009
    #.think.in infoDose #28 (29th Apr - 8th May)