Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have Microsoft SQL Server 2008 which we host some databases on. We currently use Windows Integration for authentication.
We are starting to need the support of authenticating scripts from ASP.NET and other applications. These applications need to use “script credentials” as they run without a user logged in. We are not really wanting to do this with intergrated Login as we do the adminstrators, we are looking at SQL authentication. Does doing this lower our security?
Yes it does.
Use an NT service account that can be configured to only run on certain servers.
Also, you can apply any rights (such as login interactively) using group policy.
SQL logins, although you can use the AD group policy for passwords etc, are inherently more insecure
You don’t have to make this account sysadmin on SQL Server
Edit:
Some reasons for insecurity at the system and solution level, not SQL Server.
Password must be in plain text somewhere (code, app.config, etc).
For a service account running an IIS App Pool, it does not have to be.
No restrictions on what client machine you use. That is, the service account can be limited to app or web server.
You may still need NFTS or UNC rights somewhere: SQL logins can not deal with this.