Running self-hosted OWIN Web API under non-admin account

Question

Is it possible for a self-hosted OWIN Web API to run under a non-administrator account? I have already tried dozens of url reservations and nothing works. The service fails to start with "Access is denied". It works when the account is added to the administrator role but I don't want that. Code below is running on Win 7 framework 4.5.2.

//install-package microsoft.owin.hosting //install-package Microsoft.Owin.Host.HttpListener  StartOptions options = new StartOptions(); options.Urls.Add("http://localhost:5000/"); //options.Urls.Add(string.Format("http://{0}:5000", Environment.MachineName)); //options.Urls.Add("http://+:5000/"); //options.Urls.Add("http://*:5000/");  using (WebApp.Start<WebAPISelfHostMinimal.Startup>(options)) {     while (!Terminate)     {         await Task.Delay(10); //keep cpu from getting pegged     }      LogUtil.LogInfo("Terminating owin host."); } 

EDIT - this is running under a Windows account.

C:\>netsh http add urlacl http://+:5000/ user=mini2012\svcAPI  URL reservation successfully added  C:\>sc start apiservice [SC] StartService FAILED 5:  Access is denied.  C:\>netsh http add urlacl http://*:5000/ user=mini2012\svcAPI  URL reservation successfully added  C:\>sc start apiservice [SC] StartService FAILED 5:  Access is denied.  C:\>netsh http add urlacl http://localhost:5000/ user=mini2012\svcAPI  URL reservation successfully added  C:\>sc start apiservice [SC] StartService FAILED 5:  Access is denied. 

Answer 1

It looks like the problem was with the URL reservation. I didn't need one. If there is a URL reservation, it will just prevent the owin host from starting with the access denied error. Also, the default port for owin host is 5000. If there is a "dead" process that is still running on that port, it will block your service from starting. To check you can run netstat -a -b at the command prompt.

Answer 2

Your service is running (most likely) under the LocalSystem (SYSTEM) account. This account is not in the Everyone security principal.

In short, to solve this, either make the namespace reservation for Anonymous Logon or change your service to run under the Network Service account which happens to be in the Everyone principal.

Third option is, of course, to create a new local/domain user, create the reservation for it and have the service run under this account. But then you'd have to worry about setting proper security permissions for it, so I'd go with one of the first two options.