I solved the problem but don't really understand whether it is a valid solution or not.
On the coresight server I had set the coresignt application to use windows authentication and to use Negotiate followed by NTLM as the order of authentication provider to use. When I switched these round to use NTLM then Negotiate it worked fine on both the coresight server and client.
My understanding was that negotiate tried kerberos first then if that failed it would try NTLM, so why switching this round works I do not know. I used fiddler to monitor the traffic between the client and server and on the server itself and I could see kerberos authentication headers being sent and received.
One other interesting point was that in PI Seerver I saw that the w3wp.exe connected as the user and coresight service account from the server machine. When you connect to coresight from the client under a different account should it show that users ID also in the user id list? Because it did not change. SO I am not 100% sure whether the second user was accessing data using the correct credentials or not.
If anyone can explain what is going on here I would be very interested to know.
I will transfer this case to TechSupport. They will contact you soon.
In network manager statistics you should see the app pool user account and the windows user account from the client both connect to the w3wp.exe.
We have Coresight 2013. When we installed we created a new website and then installed the coresight app to that website. We have anonymous authentication disabled. Only windows authentication is enabled. Negotiate is listed first in the enabled providers properties.
It has been a couple of years, but I want to say we only got this to work when we created a dns entry for the specific website. Then created spn based off of the dns entry.
Thanks for the reply. I checked this again and I found that my SPN was pointing to the wrong server! I corrected this and set the authentication back to negotiate and immediately I was able to connect to coresight using both the machine name (remotey) and localhost from the server.
I have seen the problem you mention before with DNS. On another project using the hostname did not work but the FQDN did.