Is SQL Server/Windows integrated security good for anything?

Question

The distinctions among Windows user permissions and any set of SQL Server GRANTs seem like unrelated concepts. As often as not, it seems to actually be implemented with pseu

Answer 1

It has been my experience that the response time of queries run against a database from most applications are significantly faster when connecting via SQL authentication. Removes the delay that occurs from constantly asking AD for security validation.

Performance wise SQL authentications >> windows integrated security.

Answer 2

How about the fact that if you use sql server authentication, the password information is sent accross the network as clear text. Integrated security doesn't have that problem.

Answer 3

I think the integrated security is good if it is used properly. For some reason I can't understand, a lot of companies I have worked in don't utilize the AD, the SQL permissions and the IIS security model very much.

If you had to design the SQL Server permission system, with the key requirement that it was integrated into AD, you would probably come up with something very similar. IMHO.

I like to group users into AD groups and then create group logins in the SQL Server with the various permissions. People should not have more access to data just because they have tools to connect to the database. They should have the same permissions on the data no matter how they connect.

Guest users (as in anonymous web-users) should be in an AD group of themselves, as per recommendations on IIS configuration. Giving this group only access to what they should have access to in the database could one day save the data from disaster. It is hard to read source code to find out if data is protected, much easier to survey the database permissions and the security configuration.

Also, non-integrated security is bad because the passwords always gets distributed, put into config files etc.

Answer 4

Since everyone else has discussed the benefits of Windows Authentication, I guess I'll play Devil's Advocate...

Allowing the account 'Joe User' to have access to the server means that not only can be connect with your app, but he can also connect via any other means (SQL Tools, Excel, malware, etc.).

With SQL Authentication, your app can run as a certain user and then the app can handle the database access. So when 'Joe User' runs your app, the app has SQL access... But 'Joe User' himself doesn't, which means that the aforementioned apps wouldn't be able to have implicit access to the database.

Answer 5

For an enterprise application which will run in an AD environment, using Windows integrated security is definitely the right approach. You don't want users who are already authenticated in the environment to have to manage a separate set of credentials just for your app. Note we are talking about authentication... for authorization you would still use SQL server's role based security.

Answer 6

yes of course, If you have your application level data access layer running as a service, you can use integrated security to talk to the databasem using an Application "Service Account" to log in to the server... Then you don;t have to store user passwords in the applications config file, and you are not passing passwords over the network fir each new connection made to the database