connection options to yukon

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all, i am a newbie to SQL2005. I have had experience developing apps on
..net 1.1 and sql 2000. I am currently working on developing a new solution
and looking into feasibility of using sql 2005 as the database and .net 1.1
as the front end with the enterprise library jan 2005 block to connect to
the database. I may also decide to use asp.net 2.0 depending on the new
features available which I am still exploring. The question I had is what is
the best way for an asp.net application (1.1 or 2.0) to connect to a sql
2005 database and make best use of connection pooling.

1. SQL Server Authentication

PROS

1. No need for windows accounts or cals
2. Performance

CONS

1. Asp.net app needs to store username & password somewhere.


2. Domain Level Windows Account

PROS

1. No need for application to store password
2. Easy Management in a Server Farm & DB Connectivity

CONS

1. Performance

3. Local Level Windows Account

PROS

1. No need for application to store password
2. Performance

CONS

1. Complicated management in a server farm and need to create account on
each machine with same name etc.

4. SQL 2005 Application Roles?


Can anyone make some best practice recommendations?

Much appreciated!
 
Hi,

I think for best practise, there won't have large difference from what you
do in .net 1.1 with sql2000 since all the currently implemented ADO.NET
components will also be supported by the SQL 2005 for compatiable issues.
Also, the connection pool based mechanism will continue so I think you
won't need to worry to much about SQL2005, just design/architecture your
app as in .net1.1 world. In addition, if you really concern about the
comming new versions, I also suggest you keep an eye on the SQL2005 (or
..net whidbey) in the beta newsgroup as Cor has mentioned.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Connection pooling does not depend on what method you choose to connect -
Windows auth or Sql auth.
Connection pooling depends on the fact that repeated SqlConnection objects
use the exact same connection string.

My recommendation would be to use Windows authentication over sql Auth
because it is more secure. It is more secure because there is no password to
manage :) (or it is managed by the OS).

Please let me know if you have any additional questions.

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/
My upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
 
Both SQL authentication and Windows authentication have security issues and
tradeoffs. If you use TLS you can increase the security of your SQL auth
connection but unless you're good at setting up groups/schema/logins/users,
they can be tough(er) to manage. Windows auth is slower as the domain must
revalidate the credentials on each open. Windows auth can lead to trojan
operations as the application using SSPI security runs under the credentials
of the user executing the program--credentials that might be very different
(and with different/more/less) rights than used when the application was
first written.

The point? There is no "universal" OSFA solution.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
I am leaning towards Windows Authentication too. But what about a domain
account vs local account? Any pros & cons of one over the other?

thanks!
 
If these are asp.net apps connecting to the database, I dont think the
concept of original vs final user connecting to db applies?

thanks
 
Local account is better, because the domain needs to validate everytime
otherwise. Win2k3 is a bit better because it uses kerberos tickets - sending
and validating tickets is quicker than hashes of passwords.
But if it's a local account, that kinda assumes that all your servers are
all on the same machine :-)

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/
 
Or I would have to sync the same account name & password on all servers and
maintain it which would be gruesome.. Should I revert back to sql auth in
lieu of windows?
 
Back
Top