Looking for a little help here. I've got an ASP.NET site that connects to a SSAS cube. This has worked for more than a decade with various SSAS version - most recently SSAS 2014. Website is set up to use windows authentication so each user can see only what they have permissions to. As part of upgrading the SSAS database to 2017, I've also upgraded from .NET 3.5 to .NET 4.7. My SSAS server is running on a separate server - not on the IIS server.
The code that seems to be causing problems is very simple:
AdomdConnection olapCnn = new AdomdConnection();
olapCnn.ConnectionString = ""Provider=MSOLAP;Data Source=ASServerName;Initial Catalog=SomeDatabase";
olapCnn.Open();
Opening the connection fails with a "Connection either failed or timed out". If I point to my SSAS 2014 server and database, it works fine. If I run a profiler trace, I can see that on my SSAS 2014 instance, I am connecting to AS with my credentials as expected. However, on my MSAS 2017 instance, I can see that an attempt is made to log in with 'ANONYMOUS LOGON' in the NTUserName column and the NTDomainName is 'NT AUTHORITY'. With those credentials, it makes sense I can't connect - however, I don't understand why it doesn't pick up my credentials just like the MSAS 2014 instance does.
Here is where it gets even more tricky for me. It actually works from my development machine hosting the IIS - if I start the project up with or without debugging from VS 2017, I can open the connection and the profiler shows my credentials, so all the needed components to connect to SSAS is installed on the IIS/development server. Everthing also works if I connect to the website from a browser on the development/IIS server without using VS 2017.
So to sum up: From development/IIS machine, I can connect to the remote SSAS instance and from another PC, connecting to the IIS on the development/IIS machine, it fails as it tries to connect to SSAS 2017 with anonymous. Pointing to a SSAS 2014 instance, it works both from the development/IIS machine and from remote.
What am I missing here?
Well - kind of obvious solution in the end if it is on your radar, but I did not know about this, so wasted countless hours... This had nothing to do with the .NET upgrade, but rather the fact that I had separated the MSAS server out to another virtual machine. Problem was caused by the client having to do 2 jumps (from client -> web server -> MSAS server) and user accounts (service accounts) need to be configured with 'Kerberos Constrained Delegation' (see this Microsoft link: Configure Analysis Services and Kerberos Constrained Delegation (KCD) ) when to pass user credentials on when jumping more than one jump. I'm sure anyone with domain security knowledge know about it - as a 'simpel' developer, I did not :( I hope this helps someone else...