Configuring HTTP for Windows Vista

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 http://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 http://+:8000/. Your process does not have access rights to 
this namespace (see 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            : http://+: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=http://+: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 (21)
  1. myITforum Daily Newsletter Daily Newsletter October 16, 2006 The newsletter is delivered

  2. Adam says:

    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.

  3. I have a long-running service operation that needs to receive a response. What options do I have for

  4. 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.

  5. Adam says:

    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 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?

  6. 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.

  7. Adam says:

    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?

  8. Sam Gentile says:

    There is so much I want to say about important topics like Rocky’s well-written, thought provoking Semantic

  9. That’s an arms race between firewall administrators, who want to keep all traffic out, and application developers, who want to let all traffic through.  As firewalls offer more ways of restricting or filtering, application developers get more creative in tunneling their applications through innocuous data streams.

    From a user perspective though, having to remember a different port number for each service is pretty bad.  Putting everything at the same server address with a memorable path name is an attractive solution.  The alternative is virtual hosting each app with a different dns address, which gets back to a similar battle with corporate administrators.

    It also saves some resources for hosts if they multiplex off a single port.

  10. Adam says:

    I think that’s a bit of an overstatement on both sides.

    App developers don’t want to let *all* traffic through, just the traffic for the apps that they need/are developing. In fact, as a developer, I hardly ever need holes in a firewall while I’m *developing* apps – that’s what internal test environments are for. But when it comes to external testing, sure, they need a hole in the firewall, but just one tiny hole, on a single port, to a single server.

    Similarly, firewall admins generally don’t want to keep *all* traffic out, they want to keep *unwanted* traffic out. But how they keep track of what traffic is wanted and what isn’t? If it all looks the same and comes in over the same channel (HTTP over port 80), how can they tell what’s wanted and what isn’t? How can they ask an app developer if they’re finished external testing of "fooble" and can they close off access to that *single* app now if there’s no way to figure out which traffic is for "fooble" and which is for "bazzle"?

    And if someone wants to run a service with known security holes open to the world on a server? If they ask for a new port to be opened for it, the firewall admins do their job, find the CVEs for it and turn the request down, great! Security is maintained. If they just hang it off another HTTP "subdirectory" and the network gets trashed – oops!

    Running different apps off different ports allows you to audit what services are available to whom and where they’re hosted in a single place – the firewall. Tunneling other protocols through/routing around the firewall defeats the entire purpose of having one!

    I find that it interesting that MS appear to be coming down on the side of helping developers circumvent their own companies’ security policies. Still, those pesky security experts! What do they know? They’re way too paranoid and only get in the way.

    Yeah, right.

    Good to see that "secure by design, secure by default" policy shining through.

    And I don’t see how users find remembering ports any different from remembering other server data – they don’t. When I get sent connection info for a service, I don’t remember it, I keep the email with the URL and copy and paste as appropriate. If someone else needs the URL, I forward it to them. And what’s so different about copy-and-pasting the followign URLs?

    I’m not sure about what resources can be saved by multiplexing. Could you elaborate on that?

  11. This article covers some of the advanced topics that I left out of the earlier piece on configuring HTTP

  12. I deployed my first WCF service as a Windows Service today. It wasn’t as straight forward as I…

  13. I started this blog back in February hoping to produce a daily post throughout the entire month. I had

  14. Hosting a WCF service on a HTTP endpoint on Windows Vista has some issues given that you are not running

  15. A while back, when I was first doing WCF development I ran into the following exception: AddressAccessDeniedException

  16. I want to run this post as a reminder to people building and deploying services. I see people deploy

  17. Sam Gentile says:

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

  18. Enabling HttpListeners for Non-Admins

  19. says: infoDose #28 (29th Apr – 8th May)

  20. says: infoDose #28 (29th Apr – 8th May)

Comments are closed.

Skip to main content