Re: connection options to yukon
- From: <param@xxxxxxxxxxxxxxxx>
- Date: Mon, 6 Jun 2005 18:35:46 -0500
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
"William (Bill) Vaughn" <billvaNoSpam@xxxxxxxxx> wrote in message
news:uXrm28taFHA.2768@xxxxxxxxxxxxxxxxxxxxxxx
> 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.
> __________________________________
>
>
> "Sahil Malik [MVP]" <contactmethrumyblog@xxxxxxxxxx> wrote in message
> news:e1lakyraFHA.2736@xxxxxxxxxxxxxxxxxxxxxxx
>> 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
>>
>>
>>
>>
>> <param@xxxxxxxxxxxxxxxx> wrote in message
>> news:urNVrlkaFHA.2664@xxxxxxxxxxxxxxxxxxxxxxx
>>> 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!
>>>
>>>
>>>
>>
>>
>
>
.
- References:
- connection options to yukon
- From: param
- Re: connection options to yukon
- From: Sahil Malik [MVP]
- Re: connection options to yukon
- From: William \(Bill\) Vaughn
- connection options to yukon
- Prev by Date: Re: connection options to yukon
- Next by Date: RE: Problem with operator
- Previous by thread: Re: connection options to yukon
- Next by thread: Re: connection options to yukon
- Index(es):
Relevant Pages
|