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

SQL Logins: Obfuscated cleartext passwords over the wire

Windows Integrated Login with NTLM: Hashes passed over the wire

Windows Integrated Login with Kerberos: Proper secure authentication.

There is only one choice if you care about security.

Answer 2

Integrated security is only really useful for intranet apps. The pseudo logins I've seen are mostly for internet web applications.

Anyway, It's more than just not storing a password in your app, since hopefully you'd be salting and hashing your password anyway. There's also:

1. The user doesn't have to log in, which is a big deal, if you are jumping into a webapp sparadically throughout the day, or work somewhere that has multiple internal webapps.

2. User management is free, since the IT admin only has to edit the user in Active Directory.

3. User names and Role names are consistent throughout the organization.

4. User impersonation is a more secure method when accessing an internal webservice. (for example; an internet website accesses an intranet webservice)

5. The web application doesn't need to do anything extra user authorization on the database, since it's all handled seamlessly.

6. [EDIT] You also know the user in your database objects. So you can have a view only return rows associated to them. (unless you create a new SQLServer user for each app user, this would be impossible, and creating a new SQLServer user for each app user is also unreasonable)

Integrated security isn't right for everything, but for the enterprise, there's a lot of value add.

Answer 3

When using integrated security your app doesn't need to know anything or handle anything about security, also, if the user is already logged in to your domain they don't need to log into your app as well (assuming you've got impersonation set up correctly).

The biggest advantage has to be using an AD group as a login in SQL Server. This way you can give access to everyone in the "Accounts" group access to a set of sprocs, tables etc and everyone in the "Managers" groups access to a different set, all with AD. Your system admins don't have to jump into Management Studio to give users access rights to your app.

Answer 4

Many of these have been said or are similar to previous answers... With AD integration:

a) I don't have to worry about the users who have access to any given application, I can pass that off to the security guys.

b) I can restrict access at a table by table level based on groups that already exists, as well as forcing standard users to only have the ability to call stored proc's.

c) When a developer leaves my group, we don't have to change all the DB passwords (i.e. if you care about data security...)

d) It's easy to do custom logging based on the user who makes the change. There are other ways to do this, but I'm all about being lazy.

e) Integrates with IIS authentication. If you're already using IE & IIS for your intranet, this just makes life a lot easier.

Note: There are far more reasons not to use it, and I never used it before my present position. Here where everything is lined up in AD already... It's just the easiest time I've ever had with database security.

Answer 5

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 6

Integrated security gives greater flexibility in user access IMO. For example if my organization wants to limit the hours during which the developer group can access the server, integrated security is my best bet.

But it's not right for everything.

[EDIT] Also it's great for logging access. If I had to create a SQL login for each new developer in a large organization...it would probably stop happening and logins would get shared, then I'd never have confidence in the ability to point the finger at the knucklehead who dropped a table.