I am working on asp application which basically is an interface to the report server. I am currently unable to determine the source of the problem so it may have nothing to do with reporting services.
Currently the back in off this application consists of a reports and web server on a machine named tango and a SQL database server on a machine named tango.
The SQL logs show a failed login for user organization\polo$ (organization is a made up domain as i don’t what to give away where I work). There is no logon in SQL for the user polo$ and as far as I can see there is no user polo$ in the domain.
Has anyone seen this before? Can anyone account for the user polo$?
Could this be caused by reporting services trying to login to the two databases (ReportServer, ReportServerTempDB) that reporting services needs. These to databases are not on the report server. They are on tango.
Thanks in advanced
Is there a computer in the domain with the name "polo"? Network resources are accessed using the ASP.NET machine account on Windows Server 2003(BUILTIN\Network Service). The machine account name is DOMAIN\ComputerName$. The $ at the end hides it in normal views.
|||polo is the web/report server for the application.|||DOMAIN\polo$ is the name of the machine account for the web/report server. You need to grant access to ReportServer and ReportServerTempDB to DOMAIN\polo$.|||Where can I get more information on this asp.net machine account? I don’t understand why it would be trying to access the database.
Secondly when I give it access to the database other user accounts stop working. It is like the asp.net machine account took precedence over the permissions I had set for a normal user.
|||This article (http://www.awprofessional.com/articles/article.asp?p=357694&seqNum=2&rl=1) explains the accounts that various Reporting Services components run under on Windows 2000 Server, Windows XP, and Windows Server 2003. I suspect that you selected service account for accessing the SQL Server hosting the Reporting Services databases. You can change that option to a domain account using the rsconfig utility from the command line.|||I was after information on SQL and ASP.NET machine account.
Because as I give the ASP.NET machine account access to the databases other user accounts stop working. It is like the ASP.NET machine account took precedence over the permissions I had set for other users.
Is this behavior normal for the ASP.NET Machine account.
|||I've honestly never seen other logins stop working when you enable the machine account. SQL Server just sees the incoming access token (DOMAIN\pogo$, DOMAIN\MyName, or whatever) and grants the appropriate permissions. Adding a user shouldn't affect the permissions for other users. Can you query using Query Analyzer and/or Enterprise Manager? Both those tools would be running under your current account. What exactly do you mean when you say the other user accounts stop working? What is the exact error message that you receive both before and after adding the DOMAIN\pogo$ account?|||After giving the machine account access to all stored procedures and databases...Our application threw a stored procedure can not be executed user has insuffiecent privleages or something like that. When looking at the stored procedure the user did have premission to execute the stored procedure in question.
What im intersted in finding out though is why when i create a connection in my asp.net code do i get 2 logins occur One of the asp.net machine account and one of the user i am impersonating. In the sql error logs i get a login failure for the asp.net machine account. I want to know why the asp.net machine account is tyring to log on to sql in the first place when the asp.net application is impersonating a diffrent user.
I see you have read my other post at http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=66810. Which pretty much explain what i have just said. Please write all posts concerning this problem into the above mentioned thread. Thanks for you help so far.
I dont belive this to be a reporting services error anymore.
Regards
Dean Dalby
No comments:
Post a Comment