|
.net
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
SQL Server does not exist...<Posted yesterday to microsoft.public.dotnet.framework.aspnet.security, but no responses garnered. For mpsc readers, this is a fairly common error encountered when connecting from ASP.Net 1.1, but I've followed all the help I can find online and it hasn't fixed my problem yet. So any ideas for troubleshooting would be welcomed> Yet another person suffering from the infamous "SQL Server does not exist or access is denied problem". I've looked through a fair bit of the checklists, but none have resolved my problem as yet. Here's what we're using: Machine running ASP.Net is either a Window 2000 Pro or Windows XP Pro box (tried both). The server is Windows 2003, running SQL Server 2000. We have an ASP.Net 1.1 application that consists of a simple set of pages/code behind and a separate DLL which performs the data operations. The DLL knows how to find it's own connection string from the registry (uses SQL Authentication, BTW) If we add the data DLL to a Windows Forms application, it connects fine, so we know that the connection string stored in the registry is correct. We've also demonstrated that we can connect using Query Analyzer, using the same username/password, both whilst running under a domain users account, and whilst running under the local system account. This has led me to suspect it's "something" special to ASP.Net. We've unregistered/reregistered ASP.Net using aspnet_regiis (also, bear in mind that we get the same from both test machines). We've tried switching ASP.Net from using the ASPNET account to using the SYSTEM account. We've tried forcing the connection to use Named Pipes, or to use TCP/IP (and we've verified that both protocols are enabled at both client and server). We've tried adding an <impersonate> element into web.config. None of these has changed the error message (other than it taking longer to error when we forced tcp connection). We've verified under all these circumstances that we don't even get a login failure in profiler. So, what I'm looking for is more ideas of where we should look? Thanks in advance for any help, Damien I don't think there's anything "special" about dot net and the connection
string. If you're using "nt authentication", then you need to be aware which account asp_net uses. Look under "Security / Users" in the Control Panel. You can go here http://www.connectionstrings.com/ and experiment with the different connection strings. Keep in mind that ~every space and ";" is important. If you type in "DataSource" instead of "Data Source", you'll screw yourself. ... Also, if you aren't sure, you can research on how to use the IIdentity to figure out who/which account you're actually using while in the dotnet world. I would say the most "Exact" connection string you can use is The IP Address for the server name. and use a sql authentication name/password pair. Use "sa" and "sapassword" (whatever your sa password is) if you have access to it. If not, make sure you create a new sql authentication username and try that. CREATE A NEW ONE to make sure the "Login" (under management/security) is not out of whack with the "(my)Database/Users". My guess is that youre running under the asp.net account name, and you're trying to use trusted security. And they aren't synced up. But that's a guess. Show quote "Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message news:1157551424.314651.280210@i3g2000cwc.googlegroups.com... > Hi Guys, > > <Posted yesterday to microsoft.public.dotnet.framework.aspnet.security, > but no responses garnered. For mpsc readers, this is a fairly common > error encountered when connecting from ASP.Net 1.1, but I've followed > all the help I can find online and it hasn't fixed my problem yet. So > any ideas for troubleshooting would be welcomed> > > Yet another person suffering from the infamous "SQL Server does not > exist or access is denied problem". I've looked through a fair bit of > the checklists, but none have resolved my problem as yet. Here's what > we're using: > > Machine running ASP.Net is either a Window 2000 Pro or Windows XP Pro > box (tried both). The server is Windows 2003, running SQL Server 2000. > > We have an ASP.Net 1.1 application that consists of a simple set of > pages/code behind and a separate DLL which performs the data > operations. The DLL knows how to find it's own connection string from > the registry (uses SQL Authentication, BTW) > > If we add the data DLL to a Windows Forms application, it connects > fine, so we know that the connection string stored in the registry is > correct. We've also demonstrated that we can connect using Query > Analyzer, using the same username/password, both whilst running under a > > domain users account, and whilst running under the local system > account. > > This has led me to suspect it's "something" special to ASP.Net. We've > unregistered/reregistered ASP.Net using aspnet_regiis (also, bear in > mind that we get the same from both test machines). We've tried > switching ASP.Net from using the ASPNET account to using the SYSTEM > account. We've tried forcing the connection to use Named Pipes, or to > use TCP/IP (and we've verified that both protocols are enabled at both > client and server). We've tried adding an <impersonate> element into > web.config. None of these has changed the error message (other than it > taking longer to error when we forced tcp connection). > > We've verified under all these circumstances that we don't even get a > login failure in profiler. > > So, what I'm looking for is more ideas of where we should look? > > Thanks in advance for any help, > > Damien > Contrary to this advise, it is a very bad decision to use the [sa] account
for web access to a database. It should 'never' be done! -- Show quoteArnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous "sloan" <sl***@ipass.net> wrote in message news:uh8hQbc0GHA.1300@TK2MSFTNGP05.phx.gbl... > .... > and use a sql authentication name/password pair. Use "sa" and > "sapassword" > (whatever your sa password is) if you have access to it. I meant try this as a test, not a permanent setting.
Naturally, after getting sa working, you want to drill down the security model to a more specific one. Show quote "Arnie Rowland" <ar***@1568.com> wrote in message news:%23H$C7pc0GHA.4408@TK2MSFTNGP05.phx.gbl... > Contrary to this advise, it is a very bad decision to use the [sa] account > for web access to a database. It should 'never' be done! > > -- > Arnie Rowland, Ph.D. > Westwood Consulting, Inc > > Most good judgment comes from experience. > Most experience comes from bad judgment. > - Anonymous > > > "sloan" <sl***@ipass.net> wrote in message > news:uh8hQbc0GHA.1300@TK2MSFTNGP05.phx.gbl... > > > ... > > and use a sql authentication name/password pair. Use "sa" and > > "sapassword" > > (whatever your sa password is) if you have access to it. > > Still bad advice, since many folks will use it, find it works, and then
never change it. -- Show quoteArnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous "sloan" <sl***@ipass.net> wrote in message news:%230sqKwc0GHA.4016@TK2MSFTNGP02.phx.gbl... > > I meant try this as a test, not a permanent setting. > > Naturally, after getting sa working, you want to drill down the security > model to a more specific one. > > > > > "Arnie Rowland" <ar***@1568.com> wrote in message > news:%23H$C7pc0GHA.4408@TK2MSFTNGP05.phx.gbl... >> Contrary to this advise, it is a very bad decision to use the [sa] >> account >> for web access to a database. It should 'never' be done! >> >> -- >> Arnie Rowland, Ph.D. >> Westwood Consulting, Inc >> >> Most good judgment comes from experience. >> Most experience comes from bad judgment. >> - Anonymous >> >> >> "sloan" <sl***@ipass.net> wrote in message >> news:uh8hQbc0GHA.1300@TK2MSFTNGP05.phx.gbl... >> > >> ... >> > and use a sql authentication name/password pair. Use "sa" and >> > "sapassword" >> > (whatever your sa password is) if you have access to it. >> >> > > Arnie Rowland wrote:
> Still bad advice, since many folks will use it, find it works, and then When I first joined my present company, the enterprise wide windows> never change it. > > -- > Arnie Rowland, Ph.D. > Westwood Consulting, Inc > > Most good judgment comes from experience. > Most experience comes from bad judgment. > - Anonymous > application was using sa and a blank password. I still shudder to think of it (and the day I set a password and broke several smaller apps) Why do I always forget to include some relevant information in my posts though? We're using sql authentication already, not intergrated security, so I'm thinking it cannot be a user issue (since we can connect using this user when in a windows forms app) I have subsequently used netcap and Network Monitor, and I am seeing what looks like traffic between the two machines, but I'm still seeing nothing in profiler. (I'm worried we might not have shutdown everything that might be doing SQL work between the two machines, but I'm definitely seeing SQL Traffic (connections to port 1433)) Where do I look next? Damien on the 2003 server, set the identity of the app pool to a domain account
with acces to the database. then be sure in the web config impersonate is false. -- bruce (sqlwork.com) Show quote "Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message news:1157551424.314651.280210@i3g2000cwc.googlegroups.com... > Hi Guys, > > <Posted yesterday to microsoft.public.dotnet.framework.aspnet.security, > but no responses garnered. For mpsc readers, this is a fairly common > error encountered when connecting from ASP.Net 1.1, but I've followed > all the help I can find online and it hasn't fixed my problem yet. So > any ideas for troubleshooting would be welcomed> > > Yet another person suffering from the infamous "SQL Server does not > exist or access is denied problem". I've looked through a fair bit of > the checklists, but none have resolved my problem as yet. Here's what > we're using: > > Machine running ASP.Net is either a Window 2000 Pro or Windows XP Pro > box (tried both). The server is Windows 2003, running SQL Server 2000. > > We have an ASP.Net 1.1 application that consists of a simple set of > pages/code behind and a separate DLL which performs the data > operations. The DLL knows how to find it's own connection string from > the registry (uses SQL Authentication, BTW) > > If we add the data DLL to a Windows Forms application, it connects > fine, so we know that the connection string stored in the registry is > correct. We've also demonstrated that we can connect using Query > Analyzer, using the same username/password, both whilst running under a > > domain users account, and whilst running under the local system > account. > > This has led me to suspect it's "something" special to ASP.Net. We've > unregistered/reregistered ASP.Net using aspnet_regiis (also, bear in > mind that we get the same from both test machines). We've tried > switching ASP.Net from using the ASPNET account to using the SYSTEM > account. We've tried forcing the connection to use Named Pipes, or to > use TCP/IP (and we've verified that both protocols are enabled at both > client and server). We've tried adding an <impersonate> element into > web.config. None of these has changed the error message (other than it > taking longer to error when we forced tcp connection). > > We've verified under all these circumstances that we don't even get a > login failure in profiler. > > So, what I'm looking for is more ideas of where we should look? > > Thanks in advance for any help, > > Damien >  |
|||||||||||||||||||||||
Other interesting topics