I have a WCF WSDualHttpBinding service. The service is contained in a WindowsService with account type LocalSystem.
The service is attempting to access a network file stored on another machine on the same network as the service, e.g. \\dataStoreMachine\\myshare\\fileToOpen.txt . If the service is running on dataStoreMachine (the same machine that stores the file), the file is opened succesfully. However, if the service is running on another machine in the network, the file is not found. Is this a permissions issue? I've given read permissions on the network share. Is there something that needs to be specified in the service bindings so it has the correct rights? The file can be browsed to from the machine running the service within win explorer, so I know the file is really at the location it's looking at it for.
Both machines on the network (a VMnet) are not on a specific domain, but have the same username, and blank passwords.
The LocalSystem account doesn't have any rights to network access. Assuming your servers are part of an ActiveDirectory domain, you should use the Network Service account to run the service. You'll need to give read permission for the share to the specific domain accounts assigned as the machine account of the servers. This is usually something like: YourDomain\MachineId123 where the MachineId123 is the actual machine name in the domain.
If you servers aren't in a domain, then you can use the synchronized passwords on identical local accounts technique. I would avoid this if at all possible because in the real world, it is very easily broken by a password change. Each server would have a local machine account named something like File123Shared and would have the same password as the same account on the other machines. You would run your service using that local account after configuring it to be able to run as a service and any other permissions it may need.
Related
I'm specifically trying to do this with Apache Storm (1.0.2), but it's relevant to any service that is secured with Kerberos. I'm trying to run a secured Storm cluster in Docker. There are a number of out-of-the-box docker images out there for Storm, and they work great unsecured. I'm using https://github.com/Baqend/docker-storm. I also have Storm running securely on RHEL VM's.
However, my understanding is that Kerberos ties hostnames to principals, so if I'm making service foobar available to clients, I need to create a principal of foobar/hostname#REALM. Then a client service might connect to hostname with principal foobar, Kerberos will look up foobar/hostname#REALM in its database, find that it's there (because we created a principal with exactly that name), and everything will work.
In my case, it's described here: https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_installing_manually_book/content/configure_kerberos_for_storm.html. The nimbus authenticates as storm/<nimbus host>#REALM, and the supervisors and outside clients authenticate as storm/REALM. Everything works.
But here in 2017, we have containers and hostnames are no longer static. So how would I Kerberize a service that runs in Docker Data Center (or Kubernetes, etc)? I have to attach an unknown hostname to the server authentication. I imagine I could create a principal for all possible hostnames and dynamically pick the right one at startup based on where the container lives, but that's kludgy.
Am I misunderstanding how Kerberos works? Is there a solution here that I don't see? I see multiple examples online of people running Storm in Docker, but I can't imagine that nobody's clusters are secure.
I don't know Apache Storm or Docker, but based on previous workings with JBOSS in a cluster in which an inbound client could be connecting to any one of a possible number of different hosts, then you would simply assign a virtual name to the entire pool at the load balancer and kerberize the service according to the virtual name instead of individual host name at the host level. So if you're making service foobar available to clients, you need to create a service principal (SPN) of foobar/virtualhostname#REALM in your Directory to kerberize the service with. You assign that SPN to a user account (not a computer account) to give it the flexibility to work with any Kerberized service which uses that SPN. If you are using Active Directory, you must create a keytab with the SPN inside of it, and place the keytab on each host running the kerberized service instance foobar/virtualhostname#REALM.
I have developed a WCF service in visual studios on a machine which is on a domain network. I hosted it in IIS by first publishing to a folder. Then I created a new site on IIS, so I set the physical path to that folder that contains the published files. I browsed the new site and am able to access the service page.that is on the host machine. However, when I try accessing this on other computers within that network using the same address, it didn't open. I am able to access it only on the host machine. Please how can I make it accessible to other computers in the network and also generally on the internet. Am using impersonation set to true, with a specified username and password. I set the credentials on IIS to the same username and password...thanks... Expecting your solutions..
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.
Have an app on server ion. It calls a webservice on server2. Endpoint of that service is to write a pdf file on server3.
As a developer in dev on my laptop it works. As a deployed app it fails on the write.
IIS6, Windows 2003 servers as well as VS2008
AppPool Identity as network service will not write the file. If I use a "fake" user in AD the app pulls no data and fails to start up properly.
Any ideas?
TIA
My guess is that the credentials that are running the app on server2 does not have write permissions to server3 (assuming server2 uses a UNC path to write to the filesystem on server3).
The user account that runs the IIS Application Pool (or however credentials are assigned to your app(s)) on Server2 will need write access to the share/UNCpath on server3; generally this means you cant use NetworkService.
If you change the user account in IIS on server2, you'll need to take into account all the implied permissions that the existing user account (assuming NetworkService) has on server2.
Including Filesystem, Registry, Metabase, etc permissions; the list could be very long and complicated or short and irrelevant (depending on your implementation on servers1/server2/server3).
For all my implementations, we use AD User accounts that are designated as Service Accounts; with extremely limited permissions on the servers, each App would have its own Service Account, and any touch-points would require explicit permissions applied. Thus, an account would be setup for the app on Server2 and the explicit permissions would be configured on Server2 to run the app, and the UNC path/share and NTFS permissions on Server3 would be applied explicitly for the file transfer.
Hope this helps.
I am trying to Access mapped network drive from wcf service hosted on IIS7. It says path could not be found. However when I m using visual studio development server, it is able to access it. I have tried impersonation but of no avail. Please let me know what are the settings I have to set in IIS And also on File server if any. Thaks in Advance
http://support.microsoft.com/kb/257174
Drop that mapped drive approach and use UNC path instead.
I know this is an old post, but thought I'd share my solution. Had the same problem; couldn't access a network drive from my WCF running in IIS. I tried a virtual directory providing my network credentials which didn't work.
The solution that worked for me was to create an application pool in IIS for my service to run under. Then I gave the application pool network credentials. Changed my service to run inside this application pool and now the service can access the network share.
So my steps were:
1) Create a new application pool in IIS. Right-click 'Application Pools' in the Connections window. Then 'Add Application Pool...'. Give the new pool a name and choose the framework. I left the other settings as default. 'Ok'.
2) Change the identity of the new application pool. In the Application Pools list, right-click on your new pool and go to 'Advanced Settings'. Under 'Process Mode', open the 'Identity' details. Select 'Custom account:' then provide the network credentials that have access to the network share. Then 'Ok', 'Ok'.
3) Change the pool your service is running in. Select your service application then click 'Basic Settings...' (on the Actions pane). Click 'Select...' in the pop-up. Change the Application Pool to the new pool you created. Then 'Ok', 'Ok'.
Now your service should be able to access the network share using the supplied credentials. You can test using your credentials but I'd recommend using a service account (virtual account with no password reset policy) when you deploy your service.
Hope this helps others!