Is SQL Server/Windows integrated security good for

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 pseudo-logins for database roles; but that doesn't map usefully back to Windows permissions. Assuming single-login identity verification, why not just go with the simplest possible database roles?

EDIT:
So far we've picked up the single benefit that you don't need to store a password in your application; but that seems more like a trivial beneficial consequence than a design goal; there are lots of other more direct ways to achieve that, without closely coupling the entire security apparati of both universes.

EDIT AGAIN:
Doesn't anyone else have any benefit to suggest, other than single login and ability for SD to maintain groups, thereby duplicating the capability for groups (based on the same user login) already existing in SQL Server?

The group issue has several flaws, including the assumption that the AD manager is assumed to be equally qualified to maintain both; and it excludes any network connections that aren't part of AD (thereby locking you into MS technology.)

And to put it in best-practice terms, you've built in coupling of systems, which is generally conceded to be a Bad Thing.

Answer 1

I guess it basically down to "not reinventing the wheel" and taking advantage of the "many eyes" effect.

Using Windows authentication you leverage the power of Windows integrated security, on top of which you can add your own stuff if so you wish. It's an already matured system which has been tested millions of times, sparing you the effort (and on your clients, the cost) of making your own mistakes and discovering/solving them later.

And then plenty of people are constantly scanning the Windows authentication process, checking it for vulnerabilities, exploring ways to bypass it, etc. When a vulnerability is openly disclosed and a fix for it gets created, your application just got a "free" security enhancement.

In my current work we have AD groups as SQL logins, so we assign SQL permissions based on membership to AD groups. So all members of the sys engineering group have some permissions, the DBAs have other, normal users others, supervisors others, etc. Adding new users or changing their permissions is a simple thing to do, only done once at AD and they immediately get the permissions they should get at the database.

Post Edit:

Expanding a bit on the "reinventing the wheel": To an AD account I can deny the right to login to a specific machine - or lock it out of everymachine save one or two. I can stop them from loging in at more than 2 workstations at the same time. I can force them to change passwords after some time, plus enforcing some minimal strenght in them. And some other tricks, all of which improve security in my system.

With SQL S. users, you've got none of this. I've seen people trying to enforce them with either complicated SQL jobs or a sort of home-brewn daemon, which in my opinion is reinventing a wheel already invented.

And then you can't stop user SA (or a privileged user) loging in from any machine. I was told once of a clever way to stop a brute-force attack over a SQL S. which had its port for remote login open over the Internet - administrators of the site implemented a job that changed SA's password every half an hour. Had it been SQL + Windows, they could've simply said they wanted administrator to login only from certain boxen, or outright use only the Windows authentication, thereby forcing anyone to go thru the VPN first.

Answer 2

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.