6

Microsoft says:

https://learn.microsoft.com/en-us/analysis-services/instances/connection-string-properties-analysis-services?view=asallproducts-allversions

"When connecting over TCP to SSAS, the client library will impersonate the Windows user using the specified username and password, and then connect as usual to the server."

"When connecting over HTTP(S) to SSAS, the credentials are provided to the web server based on the authentication mode configured on the web server, for example Basic auth or Windows auth. The web server will perform the appropriate Windows impersonation before connecting to the SSAS server, therefore providing the correct credentials flow to the server."

However, when I do this:

 using Tabular = Microsoft.AnalysisServices.Tabular;

 using (Tabular.Server server = new Tabular.Server())
 {   
    //connectionString = "Provider=MSOLAP;DataSource=ServerIP;UserID=xx;Password=xx;Persist Security Info=True;Impersonation Level=Impersonate;"

    server.Connect(connectionString);
 }

It uses the credentials of my user account that's running the code, not the the UserID and Password in the ConnectionString.

How can I get it to connect via "TCP"?

UPDATE: Using the suggestion from @GregGalloway and logic from here: I've implemented an Impersonator class. With it I've updated my code to do the following:

using (Tabular.Server server = new Tabular.Server())
{
     using (new Impersonator("UserName", "Domain", "Password"))
     {
           server.Connect(connectionString);
     }
}

Unfortunately, when I profile the call to the SSAS server, I can see that it is still using the same credentials as before and the connection to the server is successful regardless of any credentials being passed to the constructor. Stepping through the code I can see that no exceptions are being thrown at any point.

Cody
  • 161
  • 7
  • Persist Security Info=True uses windows credential so remove this option. The database has to have the user added to the credentials of the database instead of Windows Credentials. – jdweng Feb 04 '22 at 17:50
  • @jdweng, per the article I've linked, "Persist Security Info Valid values are True or False. When set to True, security information, such as **the user identity or password previously specified on the connection string**, can be obtained from the connection after the connection is made. The default value is False." Can you clarify what you mean by "The database has to have the user added to the credentials of the database" ? – Cody Feb 07 '22 at 14:15
  • SQL Server has two types of credentials 1) Windows where the login credential of the user is used. No password is needed. When client is on a different machine from server a Group Account (group policy) is used where the group password is on a password server 2) SQL where the user name and password is stored in the database. – jdweng Feb 07 '22 at 15:24
  • @jdweng I've removed that portion from the connection string and the results have not changed. My issue here is not that the credentials in the ConnectionString are incorrect, but that the credentials supplied are ignored entirely. I can pass in blank strings and it will still connect using the credentials of the user executing the web application. – Cody Feb 07 '22 at 17:32
  • That is what is suppose to happen. The credentials being used is the user login. If you try with a different user that is not on the access list it will fail. – jdweng Feb 07 '22 at 18:13

1 Answers1

-1

If your app or web app isn’t already running under those credentials then you will need to impersonate that identity in your code before you connect. Here is an example.

GregGalloway
  • 11,355
  • 3
  • 16
  • 47
  • I've attempted to use your example and it still connects to the ssas server as the user account that is running the code, not the user account that is passed into the impersonator. Code snippet used: `using (new Impersonator("UserName", "Domain", "Password")) { server.Connect(connectionString); } ` I've confirmed no exceptions are thrown from the Impersonator class. – Cody Feb 07 '22 at 14:44