WCF Service
I am developing a WCF Service and it needs to communicate with a com application running on the system.
I have tested the service with ASP.net development server it works fine. now when i run it from IIS the service can't communicate with the com application.
Issue is IIS runs in a different user account 'Application pool', than the one user is logged in. The COM file run on the user account user is logged in. So the that is the reason they have issue communication. Or at least that what i think.
What i did was i created a new application pool in IIS and in advance setting i changed the process model identity to local system. but it did not work....
i need ideas how to make the make the com and the service to run in the same account.
Any idea will be much appropriated.
IIS not only runs under a separate account, but also runs under a separate login session that is completely separated from the interactive users session. The COM object must be possible to invoke without a user even being logged on if you are to use from IIS.
Related
I'm looking to find out if there are any inherent restrictions when running an executable from a scheduled task that calls a web service while there are no users logged on?
I can't see any inhernt issue if the user that the taski runs under has the correct permissions but would there be any issues connecting over port 80 to a web service?
Thanks in advance.
If any authentication is required for either a web proxy, the web service, or anything else, you'll need to store the password.
You will find a bit of an overview at https://blogs.technet.microsoft.com/askperf/2015/02/18/help-my-scheduled-task-does-not-run/ that covers this.
My setup
ServerA is running a web app on IIS 7 using a local IIS Application
Pool identity.
ServerB is running MSMQ, hosting a private queue
we'll call MyQueue
Using the Message Queueing snap-in on ServerB, I have configured MyQueue to grant Full Control to the ServerA's domain account (ServerA$) as well as the ANONYMOUS LOGON user
What I Want To Happen
I want the web app on ServerA to send a message to MyQueue on ServerB
What is Actually Happening
The message never shows up on ServerB and I get no error message. I have turned on negative source journaling and can see that I'm getting an "Access Denied" error in the dead letter queue.
If I grant Full Control to Everyone, then the message shows up, but I don't want to do this.
Why I Thought This Would Work
This article about IIS Application Pool Identities says that
Using the Network Service account in a domain environment has a great
benefit. Worker process running as Network Service access the network
as the machine account. Machine accounts are generated when a machine
is joined to a domain. They look like this:
domainname\machinename$,
For example:
mydomain\machine1$ The nice thing about this is that network resources
like file shares or SQL Server databases can be ACLed to allow this
machine account access.
WHAT ABOUT APPLICATION POOL IDENTITIES?
The good news is that application pool identities also use the machine
account to access network resources. No changes are required.
Based upon that information, I would assume that granting MY_DOMAIN\SERVERA$ permissions on MyQueue, then things should work. But they aren't.
Any idea what I'm doing wrong?
This question is ageing now, but I've managed to query MSMQ from an IIS application using an ApplicationPoolIdentity user:
Go to the application pool list in the IIS Management Console and note the application pool name for the desired application
Right-click on the MSMQ queue in Server Manager > Properties > Security
Click Add
Enter the object name IIS APPPOOL\{application pool name from step 1}. This should auto-complete to the name of the application pool
Grant the required permissions - generally this will be Peek Message and/or Receive Message
It's better to avoid granting permissions to Everyone.
Reference: https://serverfault.com/a/81246/24816
I have just stumbled upon this and have found resolution in my case, if I setup IIS to run as the network service account the remote queue will receive the message I end to it.
This has eaten up a lot of my time today, now I need to work out if running IIS as network service is actually ok and does not break anything else.
I have a .NET application that runs in the background and collects information from Windows client workstations. It needs to send this information to a server in a different Windows domain. The application behaves similar to a Windows service (although it is not a true Windows service) in that it runs behind the scenes without the user's knowledge. Therefore, when my server needs to authenticate the workstations, the user cannot be prompted to enter a password or select a certificate--the authentication needs to happen without bothering them for input.
If both the workstations and the server were in the same domain, then I'd probably just use WCF with Windows Integrated Authentication aka Kerberos. But since they're not I need a different strategy. Any ideas?
If you establish cross-realm trust between the domains, you can use Kerberos. In this case, the minimum needed is for the realm of the server (B) to trust the realm of the clients (A). This allows foo#A to acquire a ticket for bar#B.
I have a .net/C# application when launched on a test server running VMWARE / Windows Server 2008, receives a USERPROFILE Environment Variable pointing to C:\windows\system32\config\systemprofile, but other applications seemingly built in a similar fashion inhert the correct value of C:\Users\{username}.
A slight twist - the application receives the correct value when run locally on my development machine. So I'm thinking this is a profile/registry issue with some combination of setting in my app.
The issues is manifested when you attempt to open an OpenFileDialog or similar. You get the exception "Location is not available: C:\Windows\system32\config\systemprofile\Desktop refers to a location that is unavailable..."
Any ideas?
UPDATE: The application is WPF running web services against IIS via WCF. Locally in development I am using IISExpress. I've found that after touching the WCF services in the client, the application inherits the APPDATA and USERPROFILE of the IIS AppPool the services are running under. If I adjust the AppPool values to use my user account instead of ApplicationPoolDefault and set LoadUserProfile = true - things work. Obviously this is a bad thing. As an alternative, I cache off the environment variables when the WPF app runs, and after it initially connects to WCF, I reset the variables. This appears to get around the issue but I'd like to solve it a better way but I have no idea what is influencing this behavior in WCF and my IIS Services.
It might have to deal with what account the web app is running under in IIS. You can change it from the default "Network Service" account to an actual user account.
Is it possible to spawn a process on a remote server, from a WCF service hosted as Windows Managed Service, when the service is running as LocalSystem?
I need people to be able to execute things on remote servers under the context of their own accounts (basically like PSExec - which isn't an option).
I've made some half-hearted attempts to do this before, but when using process.start, cannot get the process to run as a specific user, if the Windows service hosting the WCF component is running as LocalSystem.
I know this can be acheived by other methods, but I specifically would like to know if the above is achievable - Windows service running as LocalSystem & hosting WCF service, then spawning a process as a specified user.
Thanks
Mick
You could use the Process.Start method which allows you to specify the user under which the process will run.