Search code examples
appfabric

Unable to connect to AppFabric Cache Server


I have setup an appfabric(v1.1) cache server. The service is running under a service account and cluster configs are stored in SQL Server. the service account has rights on the sql server and able to configure successfully.

The admin console ,when opened with the service account user, is able to access cache.

But the problem is when i tried to connect to this caching service from a different machine, it is unable to connect.

ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry later

When i tried with xml configuration in a file share and service running in "NetWorkService" account, i was able to connect.

Following settings are verified on caching server.

  • Service is up and running on port 22233.
  • Firewall is turned off.
  • The client machine is granted permission to access cache cluster.

Solution

  • Running AppFabric cache as anything other than a “Network Service” is not supported.

    Here’s the official documentation that hints at the limitation:

    The Caching Service is installed to run under the Network Service account. This means that for operations over the network, the Caching Service uses the security credentials of the cache server's domain computer account. The Caching Service uses the lower-privileged Network Service account to help mitigate the damage that could be caused by malicious attacks

    But if you don’t find that convincing there’s this forum post from a MS person:

    Velocity service running as Domain User is NOT supported.

    If you think this is a horrible limitation… I agree with you.

    AppFabric cache is a 100% WCF implementation. When I ran into this problem, I turned on WCF tracing and found the exception “The target principle name is incorrect”. AppFabric cache does not expose the ability to configure the principle.

    In my testing with the cache running under a domain account, I found that if I called the cache across a domain boundary: It worked. If I called it from within the same domain it failed. My infrastructure guy said that the behavior made sense to him based on how credentials were presented in the different scenarios.