SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


RS SOLUTION - Logon failure: unknown user name or bad password. (Exception from HRESULT: 0x8007052E)...


RS SOLUTION - Logon failure: unknown user name or bad password. (Exception from HRESULT: 0x8007052E)

Author
Message
Ben Sullins-437405
Ben Sullins-437405
SSC-Addicted
SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)

Group: General Forum Members
Points: 499 Visits: 267
I'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!


Cheers,

Ben Sullins
bensullins.com
Beer is my primary key...
rholt-710769
rholt-710769
Valued Member
Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)

Group: General Forum Members
Points: 60 Visits: 64
my 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 Holt
Ben Sullins-437405
Ben Sullins-437405
SSC-Addicted
SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)

Group: General Forum Members
Points: 499 Visits: 267
Hey 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...


Cheers,

Ben Sullins
bensullins.com
Beer is my primary key...
rholt-710769
rholt-710769
Valued Member
Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)

Group: General Forum Members
Points: 60 Visits: 64
my 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!
Ben Sullins-437405
Ben Sullins-437405
SSC-Addicted
SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)SSC-Addicted (499 reputation)

Group: General Forum Members
Points: 499 Visits: 267
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!


Cheers,

Ben Sullins
bensullins.com
Beer is my primary key...
rholt-710769
rholt-710769
Valued Member
Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)

Group: General Forum Members
Points: 60 Visits: 64
i 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.

Ben Sullins (4/14/2008)
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!

Jacob Luebbers
Jacob Luebbers
SSChasing Mays
SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)

Group: General Forum Members
Points: 600 Visits: 1215
Ben Sullins (4/14/2008)
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.


Not to take away from what Ben is saying, but watch out with this. db_datareader grants select permissions to all 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
Jacob Luebbers
Jacob Luebbers
SSChasing Mays
SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)SSChasing Mays (600 reputation)

Group: General Forum Members
Points: 600 Visits: 1215
@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 here. aureolin posted a link partway through the thread (http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx) that gives you the details on correctly configuring your servers.

Regards,

Jacob
rholt-710769
rholt-710769
Valued Member
Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)

Group: General Forum Members
Points: 60 Visits: 64
Point 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.
Russ

Not to take away from what Ben is saying, but watch out with this. db_datareader grants select permissions to all 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]
rholt-710769
rholt-710769
Valued Member
Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)Valued Member (60 reputation)

Group: General Forum Members
Points: 60 Visits: 64
Jacob, 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 NOT 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 Security/Logins, could it be that i need to do something with the MS-Server2003 permissions?
Russ

Jacob Luebbers (4/15/2008)
@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 here. aureolin posted a link partway through the thread (http://msdn2.microsoft.com/en-us/library/aa905162(SQL.80).aspx) that gives you the details on correctly configuring your servers.

Regards,

Jacob

Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search