Shared datasource credentials different in different RB versions on different machines.

Question

I have RB 14X installed on one machine and RB 15X on another. The credentials for a shared dataset show differently on one system than they do on the other. On the 14X system, they show as "Do not use credentials" even though the datasource is configured with "Use database credentials", and the query designer asks for a password the first time I access the database server from RB. Then I can edit queries. On the 15X machine, it shows as "Use current windows user. Kerberose..." and I get an error with the same user/password. Why the difference? It's the same report, same report server, same shared datasource.

Answer 1

That doesn't help. I'm not using the two RB machines together. Both the report server and database server are remote. My two RB machines are next to each other. I can edit queries on one machine but not on the other. They are not connected to the report server at the same time. The data source is configured on the report server. I can change the credentials there. But they behave differently on my two local machines, even though the data source is accessed via the same report from each of my machines, and my login on the report server is the same.

Answer 2

Hi @Phil ,
In Report Builder, credentials are often used when you connect to a report server or for data-related tasks, such as creating an embedded data source, running a dataset query, or previewing a report. Credentials are not stored in the report. They are managed separately on the report server or on the local client.

If you use Remote Data Sources, The data sources that provide content to reports are usually hosted on remote servers. To retrieve data for a report, a report server must connect to the server using a set of credentials that you provide in advance or that are obtained at run time. When configuring a data source, you can specify credentials in the following ways:

• Prompt the user for credentials.
• Store credentials.
• Use Windows integrated security.
• Use no credentials.

The network environment determines the kinds of connections you can support. For example, if the Kerberos version 5 protocol is enabled, you might be able to use the delegation and impersonation features available in Windows Authentication to support connections across multiple servers. If your network does not support these security features, you will need to work around connection constraints. If delegation and impersonation are not enabled, Windows credentials can be passed across one computer connection before they expire. A user connection from a client computer to a report server computer counts as the first connection. If the user opens a report that retrieves data from a remote server, that login counts as a second connection and will fail if you specified the connection to use integrated security when delegation is not enabled.

If multiple connections are required to complete a round trip from the client computer to an external report data source, choose from the following strategies to make the connections succeed.

• Enable impersonation and delegation features in your domain so that credentials can be delegated to other computers without limit.
• Use stored credentials or prompted credentials to query external data sources for report data. The credentials can be either a Windows domain account or a database login.

Please check the following links carefully: Specify Credential and Connection Information for Report Data Sources.
Best Regards,
Joy

---

If the answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.