August 1, 2003 at 11:52 am
Hello World,
I have the following problem:
I try to connect an SQL Server 2000 from ASP with TRUSTED_CONNECTION=YES and it fails if the SQL Server runs not on the same machine as the used IIS. I get the error message “Invalid connection string”.
If I connect an SQL Server on the same machine ass the IIS is installed all works right. What can I do if I will use the IIS property “integrated security” an not an anonymous account ?!?
any idea
August 1, 2003 at 1:58 pm
Try this thread (you may have to piece it back together) -- it seems to be closely related to your question.
August 3, 2003 at 12:38 pm
First, make sure you have the User Account that you log in with on your IIS Server, setup in SQL Server as a Valid Login.
Secondly, make sure you are using the Properties of the Connection String correctly. I have never seen "Trusted_Connection=Yes". The only ones I know of are "Trusted Connection=True" and "Integrated Security=SSPI", or "Integrated Security=True".
August 4, 2003 at 2:53 pm
quote:
Secondly, make sure you are using the Properties of the Connection String correctly. I have never seen "Trusted_Connection=Yes".
We use Trusted_Connection=Yes, so it's valid. The ASP page calls an MTS object on the IIS box. The MTS object in turn uses a connection string with the T.C.=Yes to access SQL server, which is on a different box.
August 5, 2003 at 2:22 am
Correct me if I am wrong....
Is IIS using the default $IISUSER{PCNAME}account?? as this is a local account and will not have rights across the network...
surely you are better off using a SQL server account with session variables in your global.asa to handle the connection.
You could even use an application role if you wanted..
August 5, 2003 at 9:19 am
Hi - yes I know this problem of old. If you want to use pass-thru authentication (users windows account's credential are passed into SQL) you have to have IIS and SQL Server on the same box. It's all to do with NT authentication - seems that you don't have the same drawback in an Active Directory environment. For now, if you must have separate boxes for IIS and SQL you either need to go with anonymous or use a standard SQL login connection. Apparently the only other way to get pass-thru to work on sep boxes is if IIS is on a domain controller(!)
August 5, 2003 at 9:23 am
quote:
For now, if you must have separate boxes for IIS and SQL you either need to go with anonymous or use a standard SQL login connection.
This isn't true. If you refer to my comment above, you'll see that you can use MTS objects on the IIS box to access on an SQL database on a different box. While you can pass back the individual user's authentication, this will rob your ability to use connection pooling. The recommended solution is to use MTS security to validate the user, and then have the MTS packages use the same login, which can be an NT login to impersonate the individual.
August 5, 2003 at 10:23 am
Basically, unless you have Kerberos set up, the rule is that you cannot make more than 1 hop with your trusted logon credentials. For example you can go from the client IE to the IIS server -- this is 1 hop and that is all you get. If SQL happens to be on that machine then IIS to SQL is not a cross-machine hop and it will work. Otherwise, it won't. So to get to the second machine, you must do some kind of impersonation which will require a second accountname and password hardcoded in some location on the IIS server to get to SQL on another machine. That location might be MTS/Component Services or hard-coded into a connection string in an ASP/ASPX page.
August 5, 2003 at 11:10 am
I guarentee that we are using a trusted connection with our MTS objects. Bottom line: no hardcoded passwords.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply