I'm following this tutorial and seems like to implement WCF in my application it would need to run with administrator privileges.
I want to use remoting only to communicate between processes in the same machine. Anyway, everyone seems to recommend WCF even when this is the case. But if this will require my application to run only with administrator privileges then I'd rather find another solution than WCF.
There seem to be a workaround that involves running the command line and using some tool that varies depending on the Windows OS version. Is this the only way? Would I have to tell my users to run the command line and all that stuff or can this be automated, considering that my application runs on XP, Vista and 7?.
Administrative privileges are only needed for the HTTP URL namespace reservations. If you are using named pipe communication (which would be the recommended way to go for inter-process communication), then you can run fine as a normal user.
It could well be that because you are registering the endpoint information programatically that you need the elevated permissions. WCF does not require them in most circumstances.
Services such as this one require permission to register HTTP
addresses on the machine for listening. Administrator accounts have
this permission, but non-administrator accounts must be granted
permission for HTTP namespaces
Related
Azure VM, Cloud service or Web job?
I have a configurable console application which runs continuosly. Currently it is running on a VM and consumes lot of memory (it is basically doing data mining).
The current requirement is to have multiple instances of this application with different set of configuration which can be changed by specific users.
So where should I host this application such that the configuration can be modified using some front end which provides access managements(like Sharepoint),ability to stop it/restart (like WCF service) without logging on the VM?
I am open to any suggestions/ideas. Thanks
I don't think there's any sold answer to this question as there is the preference variable but for what it's worth, if it were up to me I would deploy it against individual azure VM's for each specific set of users. That way if the server resources went up because of config changes the user group made it is isolated to that group, and with azure, will scale automatically to meet the resource demand. Then just build a little .net web app to allow user to authenticate and change configuration settings.
You could expose an "admin" endpoint for your service (obviously you need authentication here!) that:
1. can return the current configuration
2. accept new configuration
3. restart the service (if needed). Stopping the service will be harder, since that leaves the question on how to start it again.
Then you need to write your own (or use a 3-party (like sharepoint or a CMS)) application that will handle your users and under the hood consume your "admin" endpoint.
Edit: The hosting part: If I understand you correctly your app is just an console application today, and you don't know how to host it? Well, there are many answers to that question. If you have a operations department go talk to them, if you are on your own play around and see what fits you and your environment best!
My tip: go for a http/https protocol/interface - just because there are many web host out there, and you can easy find tools for that protocol. if you are on the .NET platform check out Web.API or OWASP
Azure now has Machine learning to process data mining.
You should check if it's suit to you.
Otherwise, you can use Webjob:
Allow you to have multiple instances of your long time running job (Webjon scaling out).
AppSettings can be change from the Azure Portal or using the Azure Management API
Here's a simple example of my problem. I'm writing an application that self hosts a WCF service for communication only within the user's session. When multiple users run this application concurrently on a terminal services machine, all the users are happy as long as they don't have local admin rights. The problem begins if two or more users are admins, the 1st user creates the service, a 2nd user because the service has been created Globally...
Simple Win32 implementation, without WCF, would be create a named pipe with the "Local\" prefix. WCF appears to first attempt to create a global shared memory mapping, after that fails, then creates a local mapping.
Has anybody found a way to self host a WCF service that is local to the current user's session, even if the user is a local admin?
The easy way is just have each instance use a different service URL (deriving it from some characteristic of the user session to make it unique - e.g. session logon ID).
There's no way to stop the WCF binding publishing its endpoint details (aka the real pipe name) in the Global namespace if it's running with sufficient privileges to do so. But maybe you could adjust the process token privileges to disable the SeCreateGlobalPrivilege before opening the service host, if your service finds it is running as admin with elevated privileges.
I want to host wcf in window service. I've done several times before without any problem. This time After I installed the service and click on start I get the following error in EventViewer.
Service cannot be started. System.ServiceModel.AddressAccessDeniedException: HTTP could not register URL http://+:.../.../. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details).
When I host the same service, same address on ConsoleApplication - all right.
I saw the questions here and here, but none of the solutions helped me.
Does anyone have an idea?
As for your answer, that's a bit of shotgun debugging. You now have a network service with administrator privileges:
LocalSystem Account (Windows):
The LocalSystem account [...] has extensive privileges on the local computer, and acts as the computer on the network. Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects.
Most services do not need such a high privilege level. If your service does not need these privileges, and it is not an interactive service, consider using the LocalService account or the NetworkService account. For more information, see Service Security and Access Rights.
So you'd better run this service as NetworkService, and give it the proper permissions to use the port you're trying to use as explained in Configuring HTTP and HTTPS:
netsh http add urlacl url=http://+:80/MyUri user="NT AUTHORITY\NETWORK SERVICE"
I found that changing installer account to LocalSystem did the job :-)
I have a slightly complicated setup that, of course, works fine in XP, but chokes on Windows 7. It may seem like madness, but it made sense at the time!
I have a WPF application that launches and then launches another application that communicates with an external device. After launching it establishes communications with the new process using WCF (hosted by the new process) via a named pipe (net.pipe). This seems to work fine on either OS.
I wanted to make some of the functionality of the WPF application externally available to a command line program, so I set up another WCF service, this time hosted by the WPF application and again exposed it via named pipes. Again, this seems to work.
Next, I wanted to make the functionality of the WPF application available via the web. Now, it's important that the WPF application be runnable from a regular user account, so I thought the best way to make this work on Windows 7 would be to create a windows service that would provide the web service part and have it communicate back to the WPF application via the same named pipe that works fine for the command line. I implemented this and it runs fine on XP, but it chokes on Windows 7. The problem seems to be with trying to establish the named pipe connection between the windows service and the WPF application.
If I run the WPF app as an administrator, it works fine. So it seems to be a problem with the account that the windows service is running in can't communicate with a regular user account that is hosting the WCF service via named pipes. Is there a way to make this work? It seems a WCF service running in a regular user account can communicate using named pipes to another app running in the same account, but it seems it can't do the same thing with a different account.
Oddly, the reverse seems to work. The windows service does, in fact, also expose a service with a named pipe binding (it's used as an activation function since the service is running all the time). I can connect from the WPF app to this service without any problems.
My knowledge of security is somewhat limited. Can anybody shine a light on what's going on?
This question has been asked several times previously on SO. For example, see Connecting via named pipe from windows service to desktop app
The problem is that your user session applications don't possess the SeCreateGlobalPrivilege security privilege necessary to allow them to create objects in the global kernel namespace visible to other sessions, but only in the local namespace which is only visible within the session. Services, on the other hand, which run with this privilege by default, can do so.
It is not the named pipe object itself which is constrained to the local namespace in this way, but another named kernel object, a shared memory section, on which the WCF named pipe binding relies in order to publish to its clients the actual name of the pipe, which is a GUID which changes each time the service is started.
You can get round this constraint by reversing the roles - make the windows service application the WCF Service, to which your user session apps connect. The windows service has no problem publishing its service to your session. And connecting things up this way round makes more sense because the windows service is always running, whereas your session and its apps comes and goes as you log in and out. You'll want to define the service with a duplex contract, so that once the connection is established, the essential flow of communication over the WCF service can still happen in the same direction you originally intended.
The applications (WPF/Console) are creating locally scoped named pipes (this happens by default when they are unable to create globally scoped pipes). My guess is that they can communicate with each other because they can see each others named pipes because they are running under the same account.
The windows service has higher privileges and can therefore create a globally scoped named pipe for the client applications to see.
You can check out a discussion on Christian Weyer's Blog.
I've just installed XAMPP and just wondering what are the benefits of running Apache as a service?
One of the benefits is that when installed as a service is that you can limit the privileges (directories read/write access, network access, this means better security of course) of the account that runs it (the default is the LocalSystem account on Windows, you can find more about it here).
And as admin pointed out, you can also keep the service running without you being logged in all the time.
The benefits of a service in general (on Windows) :
It can automatic start at System Logon
Start and stop not related to a specific user session
Run in Background
Can run under a special account (LocalSystem, Network Service)
From Vista/Server 2008 onwards run in Session 0 (Isolation)
If you use apache only for developing purpose you can avoid to install it as service and run it when needed directly from your user session, in a production enviroment is highly recommended to install and run it as service ...
-Don't have to start it after each boot.
-If you log off the server continues running.
If you will use the server all the time, set it as a service... If not, just start it when you need it to keep the resourses free.