>Before setting up the VMs on the domain, I tried testing the service. With the security mode "None", the service could be accessed across VMs. Commenting out the security mode, the service could NOT be accessed (which, of course, is what should happen).
>
>Then we set up the VM's on the domain. But when I first started testing, I had been logged into the *machines* (as Administrator) rather than into the *domain*. With the security mode still commented out, the service could now be accessed across VMs, presumably because the machines were members of the domain (even though I was not logged on to the domain).
>
>However, and here's the problem, once I logged onto the domain, the service could not be accessed across the VMs and I get an error message: "A call to SSPI failed, see inner exception". As I said, I've been Googling and finding lots of different suggestions. I'd like to know which way to go before blindly following some of these suggestions (not sure I can easily find the inner exception either, but I haven't tried yet either). Suggestions have been made such as using an identity tag in my config and specifying either a userPrincipalName or a servicePrincipalName. Even so, I'm not sure what those should be and where they should go (client? service?). And, why were the VMs able to communicate with each other when logged in at the machine level, but not when logged in to the domain?
>

If you used the same Username/Password on both VMs for the administrator account, then Windows will automatically pass those credentials to the other machine (which is successful because they're the same). Maybe that's the reason it was successful when you weren't logged into the domain?

So it's failing when you're logged into the domain and security mode is none?