InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 21 May 2013 12:07:10 GMT20http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxI did the same thing. The solution worked.[quote][b]Nathan Griffiths-187644 (9/17/2006)[/b][hr]I had the same issue on a dev machine - turned out I head used my own domain account as the Execution Account and when I changed my password it caused this error - and the moral of the story is never use your user account when installing software! &lt;img src='images/emotions/pinch.gif' height='20' width='20' border='0' title='Pinch' align='absmiddle'&gt;cheers[/quote]Thu, 21 Feb 2013 08:32:27 GMTwfdba1838http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxOutstanding -- worked like a charm. Thank you very much!Fri, 15 Feb 2013 13:17:22 GMTsimon.bishophttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxIt helped a lot for me... yehey!!!!!!!!:-DWed, 24 Aug 2011 02:40:56 GMTmcvilbarhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxThank you!!!!!!Thu, 21 Oct 2010 13:06:22 GMTel_otro_yohttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxFor Reporting Services try this.•Goto Reporting Services Configuration (in Start Menu-&gt;Programs-&gt;Sql Server-&gt;Config Tools.•Click on Execution Account•Uncheck "Specify an execution account"Mon, 13 Sep 2010 06:55:11 GMTrperretahttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxTHAT WORKED!!! Marvellous!Mon, 16 Aug 2010 21:34:12 GMTtitanzcdhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxFantastic!This saved me lot of pain.ThanksThu, 15 Jul 2010 12:21:14 GMTVirenMannhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxI just ran into this very same problem today on SQL server 2008 and the solution still works!Thank you for sharing it makes everyone's life a little easier!Ed Leffler[url]http://www.lefflerlabs.com[/url]Mon, 22 Mar 2010 16:35:31 GMTelefflerhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspx[quote][b]Jacob Luebbers (4/15/2008)[/b][hr]@rholt:It sounds like you may be running into a Kerberos delegation issue. Are your RS server and the source DB server running on different boxes? If so you may not have your RS server setup to correctly delegate the users' credentials to the DB server, so that final "2nd hop" connection is coming through as anonymous. This has been discussed a few times in various threads, the latest I recall was in a linked server context [url=http://www.sqlservercentral.com/Forums/Topic460366-359-1.aspx]here[/url]. aureolin posted a link partway through the thread ([url=http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx]http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx[/url]) that gives you the details on correctly configuring your servers.Regards,Jacob[/quote]Jacob,Thanks for the link, that solved my problem too. The SSRS service account had a valid SPN was not enabled for delegation itself.Regards,NickSun, 30 Aug 2009 19:41:59 GMTNick Beagleyhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxThanks for your Tip.Thu, 02 Jul 2009 07:48:53 GMTvikasrana2006http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxI had same problem .....if any one help me out .. it's appriciatableFri, 26 Jun 2009 04:37:39 GMTSanjay Rama Swamyhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxMany Thanks - This worked :) :-)Thu, 23 Apr 2009 05:12:08 GMTsarkar.sumantahttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxWonderful solution.This really worked.Thanks.Tue, 17 Mar 2009 08:44:47 GMTskumarvhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxThanks for this tip. BipinFri, 14 Nov 2008 17:12:25 GMTbipindrahttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxWorked for me, too. I had a typo in my Execution Account user name. This tip showed me where to start looking. CheersTue, 08 Jul 2008 19:56:20 GMTtima-752971http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspx[quote][b]rholt (4/16/2008)[/b][hr]ok - i'm sort of understanding this, but would the fact that I have RS loaded & running [b]on my PC[/b] constitute a 2nd hop or just a single hop to the SQL Server?Everything except the SQL & SP (which are both on the SQL Server) is on my personal PC. (i will be moving it off to a Reports Server probably within the week).[/quote]That would be one hop, and therefore Kerberos delegation wouldn't be needed. I thought you were saying that it worked fine on your box with BIDS, but was failing once you deployed it to your RS server... or do I have it wrong?[quote]Jacob - this link didn't work: [b]Configuring Authentication for Reporting Services[/b] [/quote]Sorry - those two links only seem to work if you copy-and-paste them into a new browser &#119;indow. They will open your local BOL. Here's an online version of them:[url=http://msdn2.microsoft.com/en-us/library/ms160330.aspx]http://msdn2.microsoft.com/en-us/library/ms160330.aspx[/url][url=http://msdn2.microsoft.com/en-us/library/bb283249.aspx]http://msdn2.microsoft.com/en-us/library/bb283249.aspx[/url].[quote]so... i think we're in agreement that since i eventually want others to be able to run these reports, an "Execution Account" is the way to go.[/quote]Not really - an execution account is not for that purpose. As Ben just mentioned it's only intended for things like subscription emails, external network access, etc. It will be used for your data source connections if you haven't provided valid credentials otherwise, but it's much better to use either passthrough Windows credentials from your users (and thus Keberos delegation is required), Windows credentials stored securely on the server or a native SQL login for your connection string in your data sources.Regards,JacobWed, 16 Apr 2008 17:38:35 GMTJacob Luebbershttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxIf you setup the data source to use a domain account the execution account won't be used. The execution account is for unattended operations, such as sending an email via subscription, writing a file to a file share, etc...not used by the data source...Wed, 16 Apr 2008 09:13:25 GMTBen Sullins-437405http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxok - i'm sort of understanding this, but would the fact that I have RS loaded & running [b]on my PC[/b] constitute a 2nd hop or just a single hop to the SQL Server?Everything except the SQL & SP (which are both on the SQL Server) is on my personal PC. (i will be moving it off to a Reports Server probably within the week).Jacob - this link didn't work: [b]Configuring Authentication for Reporting Services[/b] so... i think we're in agreement that since i eventually want others to be able to run these reports, an "Execution Account" is the way to go. i had an Account Name: [b][quote]ReportExecution[/quote][/b] and on the SQL Server under Security/Login i created the login: [quote]ReportExecution[/quote] with the same password i used on the RS Config Mgr under Execution Account.should i NOW go into [b]Active Directory[/b] & create a UserProfile named [quote]ReportExecution[/quote] with that same password?????? [quote][b]Ben Sullins (4/15/2008)[/b][hr]As I stated in an earlier post if you setup your data source so it uses the 'Credentials stored securely in the report server' option and you provide a domain account and the 'Use as Windows credentials when connecting to the data source' box checked you should be good. Assuming the permissions on the database are setup properly. This doesn't require the 2nd hop that Jacob is describing and is generally how I've always configured my shared data sources. If you're pointing to an isolated SQL instance you could also run profiler and see what kind of requests are coming in.Hope this helps![/quote]Wed, 16 Apr 2008 07:23:26 GMTrholt-710769http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxAs I stated in an earlier post if you setup your data source so it uses the 'Credentials stored securely in the report server' option and you provide a domain account and the 'Use as Windows credentials when connecting to the data source' box checked you should be good. Assuming the permissions on the database are setup properly. This doesn't require the 2nd hop that Jacob is describing and is generally how I've always configured my shared data sources. If you're pointing to an isolated SQL instance you could also run profiler and see what kind of requests are coming in.Hope this helps!Tue, 15 Apr 2008 18:37:45 GMTBen Sullins-437405http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxA quick quote from BOL ([url=ms-help://MS.VSCC.v80/MS.VSIPCC.v80/MS.SQLSVR.v9.en/rptsrvr9/html/fee1a663-a313-424a-aed2-5082bfd114b3.htm]Specifying Credential and Connection Information[/url]):[quote][b]BOL[/b][hr]When sending a connection request over the network, the report server will either impersonate a user account or the unattended execution account.[/quote]What type of auth are you using in your connection strings in the data source(s) for your reports? If you're using Integrated Security (aka Windows Authentication) your connection from your RS server to your DB server will be done with your users' Windows credentials or the unattended exec account. Unless you've got your RS server, DB server and their service accounts correctly configured for Kerberos delegation the "2nd hop" from RS server to DB server is going to come through as anonymous, and most likely fail unless you've granted anonymous permissions (eg "public") to your report procs/queries.What credentials do you have setup on the RS server for the unattended execution account? Are they by any chance your own credentials (using your old, previous password)?This is a non-issue if you are using SQL logins in your data source connection strings. It's also not an issue when you are running the reports on your own box in BIDS as they are executing on the local machine and only making one hop to the DB server. When your Kerberos config is setup incorrectly this works (crappy ASCII diagram alert):[b]local report running in BIDS[/b] ---[WindowsAuth]---&gt; [b]DB server[/b]and this doesn't:[b]user's browser on their PC[/b] ---[WindowsAuth]---&gt; [b]your RS server[/b] ---[anonymous]---&gt; [b]DB server[/b]This BOL page should also be useful: [url=ms-help://MS.VSCC.v80/MS.VSIPCC.v80/MS.SQLSVR.v9.en/rptsrvr9/html/753c2542-0e97-4d8f-a5dd-4b07a5cd10ab.htm]Configuring Authentication for Reporting Services[/url]Regards,JacobTue, 15 Apr 2008 18:12:43 GMTJacob Luebbershttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxJacob, yes, i'm running RS on my PC and grabbing reports created here, but using data (in this case a SP running on a SQL Cluster (but both on the same Domain). now, (i've done a lot of internet searching) Yesterday afternoon i went into RS Config Mgr & under "Execution Account" i unchecked the box labelled: "Specify an Execution Account" and my reports started working. this is [b]NOT[/b] the route i wish to travel. My feelings are that, yes, there is something blocking my request for the SP to run on the SQL Cluster Node when using the ReportExecution Account. i don't know where to go on the SQL server to enable that authority. i believe i have it correctly taken care of within SQL under [b]Security/Logins[/b], could it be that i need to do something with the [b]MS-Server2003 permissions[/b]?Russ[quote][b]Jacob Luebbers (4/15/2008)[/b][hr]@rholt:It sounds like you may be running into a Kerberos delegation issue. Are your RS server and the source DB server running on different boxes? If so you may not have your RS server setup to correctly delegate the users' credentials to the DB server, so that final "2nd hop" connection is coming through as anonymous. This has been discussed a few times in various threads, the latest I recall was in a linked server context [url=http://www.sqlservercentral.com/Forums/Topic460366-359-1.aspx]here[/url]. aureolin posted a link partway through the thread ([url=http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx]http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx[/url]) that gives you the details on correctly configuring your servers.Regards,Jacob[/quote]Tue, 15 Apr 2008 07:35:16 GMTrholt-710769http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxPoint well taken, Jacob. for now, i am the sole recipient of all reports run through RS, but i will close down what i need to before i allow others to run them.RussNot to take away from what Ben is saying, but watch out with this. db_datareader grants select permissions to [i][b]all[/b][/i] tables and views in the database. For most environments this is not appropriate, especially if you are granting users access via their Windows logins. It's just asking for someone to steal your data - a least permissive model with only EXEC on reporting procs and minimal direct SELECT access to tables/views is generally better.Regards,Jacob[/quote]Tue, 15 Apr 2008 07:24:45 GMTrholt-710769http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspx@rholt:It sounds like you may be running into a Kerberos delegation issue. Are your RS server and the source DB server running on different boxes? If so you may not have your RS server setup to correctly delegate the users' credentials to the DB server, so that final "2nd hop" connection is coming through as anonymous. This has been discussed a few times in various threads, the latest I recall was in a linked server context [url=http://www.sqlservercentral.com/Forums/Topic460366-359-1.aspx]here[/url]. aureolin posted a link partway through the thread ([url=http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx]http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx[/url]) that gives you the details on correctly configuring your servers.Regards,JacobTue, 15 Apr 2008 03:32:24 GMTJacob Luebbershttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspx[quote][b]Ben Sullins (4/14/2008)[/b][hr]Yeah so if you're data set(s) read directly from the database then you need to make sure the account you're using has db_datareader on whatever DB's it is reading from. If you're calling a stored proc (recomended) then the user account must have execute privileges on the stored proc and must also be a db_datareader in the databases from which the stored proc calls.[/quote]Not to take away from what Ben is saying, but watch out with this. db_datareader grants select permissions to [i][b]all[/b][/i] tables and views in the database. For most environments this is not appropriate, especially if you are granting users access via their Windows logins. It's just asking for someone to steal your data - a least permissive model with only EXEC on reporting procs and minimal direct SELECT access to tables/views is generally better.Regards,JacobTue, 15 Apr 2008 03:25:38 GMTJacob Luebbershttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxi did what you recommended... - I also went into the Props of the SP & added "reportexecution" to the list of execution users for the sp. still the same problem.i went back to the Report Mgr and changed the Props of the Data Sources to use "Credentials supplied by the user running the report". Since i am a System Administrator so i SHOULD have permissions all over the place, i am the owner/creator of the SP, i can run the report in BIDS, yet i still get this 8007052E error.i appreciate your patience here. this is my company's first foray into Reporting Services; I see the Potential of things that can be done over our present Crystal Reports and i just want to start moving along with this.[quote][b]Ben Sullins (4/14/2008)[/b][hr]Yeah so if you're data set(s) read directly from the database then you need to make sure the account you're using has db_datareader on whatever DB's it is reading from. If you're calling a stored proc (recomended) then the user account must have execute privileges on the stored proc and must also be a db_datareader in the databases from which the stored proc calls. Hope this helps![/quote]Mon, 14 Apr 2008 11:07:31 GMTrholt-710769http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxYeah so if you're data set(s) read directly from the database then you need to make sure the account you're using has db_datareader on whatever DB's it is reading from. If you're calling a stored proc (recomended) then the user account must have execute privileges on the stored proc and must also be a db_datareader in the databases from which the stored proc calls. Hope this helps!Mon, 14 Apr 2008 10:37:34 GMTBen Sullins-437405http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxmy feeling is that i'm missing one "simple" piece.i opened SQL Serv. Mgmt Studio drilled down to Security/Logins to ReportExecution.right-clicked & opened properties. re-input the password to double check that it was/is correct.are there "server roles" or "user mappings" that need to be checked?both my pc (where reporting services is installed) and the server are on the same domain.oy!Mon, 14 Apr 2008 10:15:10 GMTrholt-710769http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxHey Russ,Are you using shared data sources? Make sure the connection string has the correct servername and that from the SSRS server you can telnet into the DB server. This should resolve at least any networking issues. Then I would say make sure whatever account you are using for your data source credentials has access to the database(s) where your query/stored proc pulls from. This needs to be done through SQL Server Management Studio. Also, are the SSRS and DB servers on the same domain? That might cause some problems as well...Mon, 14 Apr 2008 10:00:46 GMTBen Sullins-437405http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxmy knowlege of most of this is limited.but would it help to let you know that the SQL server is running SQL2005 on a MS-Server2003 OS and the server is in Cluster configuration.i'm not sure where to go on the SQL Server in order to add the credentials.i have ReportExecution as the user name & at one time had the proper credentials to get the reports running from the server, until my own username/password changed.again, i think i just need to know where on the SQL Server i need to go to add this user/password combination?thanks for your help. i've spent way too many hours trying to get over this hump and start becoming productive again.Russ HoltMon, 14 Apr 2008 09:51:35 GMTrholt-710769http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxI've been working with SSRS for years now and still come across this error from time to time. Generally the issue I find is that there are domain/networking issues that prevent the SSRS server from accessing the database server. In some instances if there is no transitive trusts between the domains than you'll need to create a local user on the db server with the same username/password as the account you're trying to use to connect. Delmar - Can you provide some more details about your network setup in regards to the SSRS and DB servers? This will help with any suggestions on resolving your connectivity issues.Generally for the data source config I choose to use 'Credentials stored securely in the report server' with a domain account and the 'Use as Windows credentials when connecting to the data source' box checked...Hope this helps!Mon, 14 Apr 2008 09:13:04 GMTBen Sullins-437405http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxi have have had the same problem - i have the RS on my PC but i'm trying to access a report from a SQL instance on a different SQL Server.it took me quite a while to get the two to see each other - my password changed & now i although the reports show up on my site & i've gone into Rpt Mgr to change the ReportExecution password - still the same error.Mon, 14 Apr 2008 07:08:03 GMTrholt-710769http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxAwesome. Thanks for the tip. Saved me lots of frustration! :DThu, 10 Apr 2008 20:46:23 GMTknahmhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspx:DThanks for your help!!Thu, 07 Feb 2008 08:12:26 GMTrene-500237http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxI tried this, but have not had any luck. I have reviewed my RS Logs and restarted the server/services several times over the past few days and de-selected the Execution account but still no luck. Just "Logon failed. (rsLogonFailed)Logon failure: unknown user name or bad password. (Exception from HRESULT: 0x8007052E) "If anybody has any otehr ideas, let me know.Fri, 28 Dec 2007 13:27:55 GMTdelmar.stewarthttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxYes. this works, thank you.Fri, 21 Dec 2007 12:04:47 GMTRachel Blumhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxThis solution really works....Fri, 12 Oct 2007 00:31:01 GMTBidyut-437210http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspx<P>Jeff,</P><P>Thanks for this - I had just about run out of hair!</P><P> </P>Thu, 19 Jul 2007 18:33:00 GMTBrian Egertonhttp://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxThanks for the solution! <img src='images/emotions/smile.gif' height='20' width='20' border='0' title='Smile' align='absmiddle'>Thu, 22 Mar 2007 08:57:00 GMTPuja-306040http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspx<P>I had the same issue on a dev machine - turned out I head used my own domain account as the Execution Account and when I changed my password it caused this error - and the moral of the story is never use your user account when installing software! <img src='images/emotions/pinch.gif' height='20' width='20' border='0' title='Pinch' align='absmiddle'></P><P>cheers</P>Sun, 17 Sep 2006 23:50:00 GMTNathan Griffiths-187644http://www.sqlservercentral.com/Forums/Topic306519-147-1.aspxNo one has responded to this topic yet. Even if you don't have a complete answer, the original poster will appreciate any thoughts you have!Mon, 11 Sep 2006 08:00:00 GMTSite Owners